merge: integrate final rover control with operator simulation workspace

docs/node/19_VESC_OPERATOR_CALIBRATION.md

@@ -57,16 +57,43 @@
 и недостаточное движение при измерении. Номер физического сломанного контакта
 не определяется по таблице без проверки распиновки и проводки.
 
+Для подготовки к измерению в Node 0.8.39-1 / plugin 0.6.6 оператор отдельно
+подтверждает неподвижность всех моторов. Бессенсорная прошивка может сообщать
+ненулевые ERPM и изменение тахометра при физической остановке: оба значения
+вычисляются из оценки положения ротора. Приложение сохраняет эти показания,
+а перед измерением повторно проверяет нейтраль приёмника, отсутствие PWM,
+малый ток и отсутствие ошибок. Это исключение действует только для
+наблюдаемого измерения Холлов в бессенсорном режиме, не для управления
+движением. Установка и реальные результаты новой версии фиксируются отдельно
+в журнале испытаний.
+
 ## Назначение и проверка вращения
 
 Назначение «левый/правый» связывает постоянный UUID VESC с местом мотора на
 аппарате. Оно нужно для адресного и общего управления, но не влияет на
 измеряемое сопротивление или параметр потерь. После смены USB-порта назначение
-сохраняется. Общий список назначений сейчас отображается в каждой карточке
-VESC; это обзор профиля аппарата, а не перечень моторов внутри одного VESC.
+сохраняется. Общий список назначений находится в разделе «Настройки борта»;
+это профиль аппарата, а не перечень моторов внутри одного VESC.
 
 «Проверка вращения» запускается отдельно от калибровки. Скорость задаётся
 в ERPM, ток задаёт верхний предел, длительность считается после разгона
 и удержания скорости. Выбор всех моторов профиля запускает совместную
 проверку; для 1×1 это два мотора. Успешная проверка на вывешенном приводе
 не заменяет проверку под нагрузкой или надёжности связи.
+
+
+### Visible forward/reverse bench rotation
+
+After Hall measurement, use **Проверка вращения** for sustained visible motion.
+Select one controller or the complete assigned profile, then **Направление
+вращения → Прямое / Обратное**, speed magnitude, motor-current ceiling and hold
+duration. Direction is relative to each VESC's existing settings, not a certified
+vehicle heading. Current is an upper torque limit, not a speed setting.
+
+Observe all motors fully stopped, raised and free before confirming each start.
+Wait for physical stop before changing direction. There is no automatic forward/
+reverse sequence. On admitted sensorless firmware, idle ERPM alone cannot prove
+standstill; the preflight records that estimate alongside electrical checks.
+Timing begins after speed settles; preparation/ramp/gaps are excluded. Compare
+VESC observations with actual movement. This is an unloaded bench test, not
+acceptance of loaded starts or the unresolved left Hall hardware fault.

docs/node/20_VESC_POWER_LIMITS_PLAN.md

@@ -0,0 +1,145 @@
+# VESC: план привода и ограничения мощности
+
+Актуализация 2026-09-24 после установки: Node 0.8.38-2 установлен, Core
+принял оба VESC; владелец подтвердил появление устройств после перезапуска.
+Ниже сохранён исходный аудит сбоя загрузки и состояние ранних сборок, а не
+текущий статус установки. Последний журнал — `17_VESC_INSTALLATION_LEDGER.md`;
+текущая очерёдность диагностики, RC-перехвата и профилей —
+`23_ROVER_CONTROL_PROFILES.md`, раздел «Приёмка и порядок».
+
+Статус на 2026-09-24: исследование и план. Пользователь попросил разобраться
+в штатном механизме VESC Tool; управление пределами пока не реализуется и
+настройки контроллеров не меняются.
+
+## Принятый результат и незавершённая работа
+
+- Оба мотора откалиброваны штатным нативным VESC Tool; калибровка, история
+  конфигураций, назначение и одиночная/совместная проверка доступны в UI.
+- Принят совместный тест примерно 30 секунд и хороший ход обоих моторов с
+  пульта по наблюдению владельца. Это проверка вывешенного привода.
+- Левый работает без датчиков, правый с Холлами. Отдельная повторная
+  диагностика Холлов не завершена; повреждённый контакт не локализован.
+- Надёжность USB не принята: после успешного теста повторялись ошибки чтения.
+- Node 0.8.36-1 с исправлением проверки нейтрали PPM подготовлен и проверен,
+  но не установлен. Это исправление не объявляется решением USB-сбоев.
+
+## Отсутствие устройств после загрузки
+
+Сегодня Node 0.8.35-1 и VESC-служба активны, без автоматических перезапусков.
+Linux не перечисляет VESC среди USB-устройств; ttyACM и serial/by-id отсутствуют.
+Во время загрузки есть ошибки чтения USB-дескрипторов и адресации (-71) на
+двух портах. Дескрипторы этих устройств не получены: приписывать им личность
+VESC или конкретную причину ошибки пока нельзя. Изменение портов не должно
+менять идентичность: назначения привязаны к UUID контроллеров.
+
+Владелец затем подтвердил подключённые USB-кабели и успешное управление обоими
+моторами с пульта сейчас. Это подтверждает работу силового питания и моторного
+управления, но не USB-канала. Первые ошибки USB зарегистрированы около 9,124 с
+от старта, процесс VESC-службы запущен на 11,111 с, Node — на 13,430 с. Значит,
+первый сбой перечисления возник до запуска нашего прикладного драйвера в этой
+загрузке. Это не устанавливает, неисправен кабель, устройство, питание USB или
+контроллер USB Mini. Никакого ручного сброса портов в аудите не выполнялось.
+
+Отдельный недостаток продукта подтверждён исходниками: drive-profile.json
+сохраняется на борту, но Service.inventory публикует drive_profile только
+внутри обнаруженных устройств. Node сохраняет отсутствующие устройства через
+реестр initialized, который обновляется при prepare; автоматически обнаруженная
+личность сама в него не добавляется. В текущем Core один VESC остаётся offline,
+второго нет в inventory, хотя архивы обоих доступны. Это не потеря калибровки,
+но модель отображения известных устройств и общего профиля недостаточна.
+
+Нужны независимая доступность профиля аппарата и сохранённый список назначенных
+контроллеров со статусом «нет связи». Нельзя выдавать сохранённые сведения за
+свежую телеметрию или разрешать команды без нового подтверждения UUID/сеанса.
+Сохранность самого файла профиля в этом аудите напрямую не проверена: у SSH
+пользователя нет права чтения. Факт сохранения установлен по реализации и
+вчерашним квитанциям; текущие архивы обоих контроллеров прочитаны через Core.
+
+## Последние подтверждённые пределы
+
+Данные из архивов 2026-09-23 21:05 UTC, а не новое чтение недоступных VESC.
+
+| Параметр | Левый | Правый |
+| --- | ---: | ---: |
+| Максимальный ток мотора | 34,2135 А | 34,4078 А |
+| Масштаб тока разгона | 100% | 100% |
+| Предел тока батареи | 55 А | 55 А |
+| Предел рекуперации в батарею | −55 А | −55 А |
+| Отдельное ограничение мощности | выключено | выключено |
+
+Значение watt max 1500000 соответствует выключенному ограничению в профилях
+Tool. Оно не является мощностью оборудования. Значение absolute current
+160 А — отдельный порог защиты, а не паспортный рабочий ток. Настройки батареи
+унаследованы и не подтверждают возможности BMS. Максимумы мотора около 34 А
+получены мастером при допустимых потерях 50 Вт. Этот параметр калибровки не
+является выходной мощностью. Временные 30 А и 2000 ERPM теста не являются
+постоянным ограничением ручного управления; квитанции подтверждают восстановление
+временных токовых масштабов после принятого теста.
+
+## Штатный механизм
+
+Базовые Motor Current Max, Battery Current Max, рекуперация и другие пределы
+хранятся в конфигурации каждого VESC. Профиль Tool задаёт масштаб тока разгона
+и торможения, скорость, duty и мощность. Процент тока не равен проценту ватт:
+ток мотора в первую очередь задаёт момент, а батарейный ток относится к
+потреблению от общей батареи.
+
+В закреплённом Tool ProfileDisplay вызывает Commands::setMcconfTemp и предлагает
+«Use until reboot» и постоянное применение. FW 5.02 поддерживает сохранение,
+пересылку по CAN и деление ватт между обнаруженными CAN-контроллерами. Поэтому
+общий профиль возможен, но исполняют ограничения отдельные контроллеры. Их
+применение влияет и на PPM-пульт; для этого не нужна повторная калибровка.
+Временное применение не требует записи каждого движения ползунка во flash.
+
+В штатной пересылке подтверждение ведущего не является подтверждением каждого
+ведомого: FW подавляет ack для пересланных команд. В интеграции нужны проверка
+состава назначенных UUID и чтение результата у каждого участника. Делить бюджет
+по случайному числу отвечающих устройств нельзя: пропавший контроллер может
+снова появиться, и общий бюджет батареи будет превышен. Конкретную политику
+частичного применения и восстановления следует определить до реализации.
+
+## Предлагаемая модель Mission Core
+
+Общий профиль привода размещается у аппарата. Он содержит уже существующую
+схему 1×1/2×2 и назначения, подтверждённый бюджет общей батареи и режим работы.
+Карточка каждого VESC хранит калибровку, паспортные основания пределов и его
+индивидуальные ограничения. Общий режим применяет согласованные значения к
+назначенным контроллерам через нативный Tool; подтверждённые ограничения
+исполняются на VESC независимо от связи с Core.
+
+Запас 20% рассчитывается от подтверждённых допустимых характеристик при
+реальном охлаждении и длительности нагрузки. Для каждой пары мотор–контроллер
+нужен допустимый фазный ток; для общей батареи — суммарный ток разряда и
+отдельный ток заряда/рекуперации. Пиковый ток нельзя считать непрерывным.
+Маркер прошивки 75_300_R2 не доказывает производителя и реальные характеристики
+платы, а приблизительные 500 Вт мотора не определяют допустимый фазный ток.
+Поэтому численный новый потолок пока не назначен. Нужны точные модели или
+подтверждённые характеристики от изготовителя и параметры BMS.
+
+## Очерёдность
+
+1. Установить состояние питания/подключений и восстановить USB-обнаружение,
+   затем проверить связь без вращения. Смена портов не должна требовать
+   повторного назначения, перезагрузка не должна скрывать сохранённый профиль.
+2. Исправить доступ к общему профилю и отображение известных offline-устройств;
+   применить и проверить подготовленное исправление нейтрали пульта через
+   версионный установщик с согласованным прерыванием служб.
+3. Сверить паспорта моторов, контроллеров и BMS; сформировать индивидуальные
+   пределы и общий бюджет с согласованным запасом. Затем реализовать профили
+   ограничений штатными средствами Tool, с резервированием и чтением результата.
+4. Завершить отдельную диагностику Холлов, сохранив принятую калибровку.
+5. Принять работу под нагрузкой, ограничения температуры/рекуперации и
+   остановку при потере связи; далее полноценное ручное удалённое управление,
+   приоритет пульта и автономный режим. Общий тест пока не означает готовность
+   всей системы управления к эксплуатации.
+
+## Первичные источники
+
+- [VESC: назначение пределов тока](https://vesc-project.com/node/180).
+- [Tool: штатные профили и применение](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/mobile/ProfileDisplay.qml).
+- [Tool: поля профиля](https://github.com/vedderb/vesc_tool/blob/01d5f10901116c311e3fb84d5a1541f663d3ce20/mobile/ProfileEditor.qml).
+- [FW 5.02: COMM_SET_MCCONF_TEMP](https://github.com/vedderb/bldc/blob/5.02/commands.c).
+
+Ops MCP на момент обновления возвращает HTTP transport error; план и свежая
+диагностика в Ops не опубликованы. Частные журналы и UUID находятся вне Git
+в outputs/rover-006-vesc-context-20260923/native-probe/boot-20260924-*.

docs/node/21_STARTUP_AND_USB_RECOVERY.md

@@ -0,0 +1,95 @@
+# Подготовка окружения, автозапуск и USB при загрузке
+
+Требование владельца от 24.09.2026: пользователь получает сборку Node,
+открывает приложение и выполняет его настройку. Все необходимые изменения ОС
+выполняет версионированный продукт. Ручные правки Linux не являются частью
+установки, диагностики с исправлением или первого испытания.
+
+## Владение настройкой
+
+Существующая страница «Настройка окружения → Сконфигурировать» использует
+профиль `ubuntu-24.04-amd64/3`. Добавлены два этапа в существующий список:
+
+- «Автозапуск приложения»: root-owned XDG entry открывает обычное окно Node
+  после входа в графическую сессию. Перед запуском оно до 180 секунд ожидает
+  HTTP-службу. Gtk.Application сохраняет одно окно на пользовательскую сессию.
+  Авторизация локального интерфейса остаётся обычной polkit-авторизацией;
+  автозапуск не выдаёт новые права и не настраивает автоматический вход в ОС.
+- «Обнаружение устройств при загрузке»: устанавливает фиксированную политику,
+  включает отдельную службу на следующую загрузку и читает возможности текущих
+  USB-хабов. Подготовка окружения не перезапускает USB-порты в текущей сессии.
+
+Системная служба Node уже включалась установщиком и работает до входа в рабочий
+стол. Открытие окна и работа борта — разные жизненные циклы. Постоянного
+интерфейса управления портами нет; обновление устройств только обновляет список.
+
+Политика и XDG entry создаются из шаблонов пакета. Повторное выполнение
+идемпотентно; чужие файлы/ссылки не перезаписываются. При удалении пакета
+удаляются только неизменённые принадлежащие продукту файлы, служба отключается.
+Пакет запрещает замену файлов во время переключения USB или незавершённого
+обратного включения. При откате до версии раньше 0.8.37 prerm также отключает эту службу и удаляет
+только совпадающие с шаблонами настройки, прежде чем dpkg удалит новые helper.
+Физическая проверка downgrade ещё не выполнена.
+
+Подтверждаемый профиль пока Ubuntu 24.04 amd64. Новые дистрибутивы и архитектуры
+должны получить собственные поддерживаемые профили и проверку dependency closure;
+этот пакет не является доказательством работы на любом Linux.
+
+## Ограниченная процедура USB
+
+1. Служба запускается до Node и VESC, только если подготовка среды включила
+   политику. После udev-settle выдерживается возраст загрузки не менее 30 секунд:
+   ядро может ещё повторять обнаружение после завершения udev-settle.
+2. Из журнала **текущей загрузки**, только transport=kernel, выбираются порты с
+   окончательным `unable to enumerate USB device` в первые 60 секунд. Более
+   позднее подключение/отключение отменяет устаревший кандидат. Ошибка чтения
+   дескриптора сама по себе не разрешает сброс.
+3. На порту и его USB 2/3 companion не должно быть дочернего устройства,
+   состояния незавершённого обнаружения, отключения или зарегистрированного
+   overcurrent. Встроенные hardwired-порты исключены. Проверяются взаимные peer
+   ссылки, поколение/адрес хаба и нахождение атрибутов в sysfs.
+4. Дескриптор каждого хаба должен подтвердить individual port power switching.
+   При ganged/no switching/нечитаемом дескрипторе порт пропускается. Поддержка
+   физического отключения VBUS всё равно зависит от железа; успешный sysfs write
+   не доказывает восстановление устройства.
+5. До первого изменения сохраняется root-owned журнал обратного включения.
+   После повторной проверки свободных портов пара отключается на одну секунду,
+   включается в `finally`; до восьми секунд ожидается новое обнаружение.
+   ExecStopPost повторяет обратное включение при остановке процесса. Уже включённый
+   порт не переключается повторно. Ошибка восстановления сохраняет pending и
+   останавливает обработку других портов.
+6. Не более одной попытки на физическую пару за загрузку, общий бюджет 90 секунд,
+   начало только в первые 180 секунд. Поздний запуск службы/перезапуск приложения
+   не сбрасывает USB. Повторный запуск сохраняет исходный результат.
+
+До чтения дескриптора тип проблемного устройства неизвестен: это ограниченное
+восстановление ошибки Linux USB, а не угадывание VESC по пустому разъёму.
+Конкурентное физическое подключение полностью не атомарно относительно sysfs;
+проверки выполняются непосредственно перед записью. Процедура не меняет драйвер
+хост-контроллера и не сбрасывает целый USB-контроллер/хаб. Она не отправляет
+команды моторам. После обнаружения обычный драйвер сопоставляет VESC по firmware
+UUID, а не по tty, разъёму или неуникальному USB serial.
+
+Результаты остаются в `/run/mission-core-usb-startup/`: inspection.json,
+result.json, attempted, при незавершённом восстановлении pending.json.
+Синтетические тесты используют временный sysfs; реальное переключение в них
+не выполняется.
+
+## Приёмка
+
+- Локально: 36 тестов подготовки/автозапуска/USB, shell syntax и diff check прошли.
+- Ubuntu qualification: 17 этапов прошли; пакет 0.8.37-1 и штатный установщик
+  сформированы, APT-план проверен. Пакет установлен штатным установщиком.
+  Хеши и результаты находятся в ledger.
+- Подготовка через поставляемый UI: все девять этапов завершены, XDG entry и
+  USB-политика созданы, служба восстановления включена для следующей загрузки.
+  Сводная проверка нашла поддержку у USB-хабов; возможности именно корневых
+  портов ещё нельзя вывести из сводного статуса. Оба VESC доступны.
+- Холодная загрузка с подключёнными VESC, сохранение UUID/назначений и отсутствие
+  вмешательства в камеры: ещё не приняты. Программный перезапуск службы не
+  заменяет этот тест. Без владельца перезагрузка борта не выполняется.
+
+Основания: Linux [USB sysfs ABI](https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/sysfs-bus-usb),
+[port.c](https://github.com/torvalds/linux/blob/master/drivers/usb/core/port.c),
+[USB error codes](https://docs.kernel.org/driver-api/usb/error-codes.html),
+[uhubctl: switching and USB 2/3 peers](https://github.com/mvp/uhubctl).

docs/node/22_BOARD_SETTINGS_SURFACE.md

@@ -0,0 +1,37 @@
+# Карточка аппарата: борт, настройки и устройства
+
+Согласовано владельцем 2026-09-24: существующую карточку аппарата разделить
+на три независимо сворачиваемых блока; повторить композицию в Node.
+
+- «Бортовой компьютер»: идентичность, связь, характеристики и существующие действия.
+- «Настройки борта»: общий профиль привода, назначения UUID и чтение ограничений VESC.
+- «Устройства аппарата»: существующий инвентарь и переход к конкретному устройству.
+
+Используется канонический DG Inspector variant=panel. Новая навигация и новые
+визуальные сущности не вводятся. Альтернатива — дополнительные окна настроек —
+отклонена владельцем в пользу блоков на существующей карточке.
+
+Открытые секции сохраняются автоматически в JSON на стороне приложения:
+в Core отдельно для каждого аппарата, в Node локально для его борта. Это
+представление оператора, не конфигурация контроллера. Изменение одного блока
+не перезаписывает состояние остальных. Пустой список означает «всё свёрнуто».
+Инвентарь и выполняющиеся команды живут выше Inspector: сворачивание не
+останавливает соединения и не скрывает ошибки сохранения.
+
+Общий профиль и назначения используют прежние проверенные команды VESC.
+Калибровка, Холлы, тест вращения и версии конфигурации остаются в карточке
+конкретного контроллера. Чтение ограничений идёт через нативный VESC Tool,
+не меняет моторную конфигурацию и не запускает мотор. Значения являются
+настройками контроллера, а не паспортными пределами оборудования.
+
+Изменение рабочих пределов мощности остаётся отдельным этапом по плану 20:
+нужны подтверждённые пределы оборудования и политика согласованного применения.
+Никаких искусственных «80% мощности» или новых токовых пределов этот этап
+не записывает. Проверки: сохранение после навигации/перезагрузки, разделение
+аппаратов, конкурентные изменения секций, ошибки JSON/связи и обе поверхности.
+
+Последующее требование владельца: добавить здесь два режима ручного управления
+ровером. Исследование источника команд, пульта и независимого RC-пути находится
+в [плане 23](23_ROVER_CONTROL_PROFILES.md). Этот режим не совпадает со схемой
+1×1/2×2; переключатель не объявляется действующим до реализации и проверки
+реального пути команд.

docs/node/23_ROVER_CONTROL_PROFILES.md

@@ -0,0 +1,595 @@
+# Профили ручного управления ровером
+
+Актуальное решение владельца 25.09.2026: оставить работающее управление двумя
+стиками; Tank/Arcade и управление одним стиком отложить до отдельного возврата
+к задаче. Сейчас Mini получает CH2/CH3, но не горизонтальную ось выбранного
+стика; новую проводку/адаптеры владелец исключил. Прототип не включать в
+production и не показывать переключение RC-профиля как применённое.
+Требование stop → neutral → manual сохранено незавершённым.
+
+Полный контрольный паспорт, конфигурации, история экспериментов и чекеры
+опубликованы в [MISSIONCOR-85 — Гусеничный ровер Node 006](https://ops.nodedc.ru/nodedc/browse/MISSIONCOR-85).
+Карточка прочитана обратно через прямой Ops MCP: все 35 структурированных
+блоков совпали с подготовленным содержимым, включая 600 параметров VESC.
+
+Статус 2026-09-24: исследование и автономный программный прототип. Рабочие
+настройки пульта, приёмника и VESC не изменены; новый режим движения на
+оборудовании пока не реализован.
+
+## Требование владельца
+
+В существующих «Настройках борта» нужны два профиля: независимое управление
+левым и правым бортом двумя рычагами и управление движением/поворотом одним
+двухосевым рычагом. Тот же профиль должен быть доступен локально на Node и
+через Core. Пульт должен сохранять возможность управления при отказе Mini.
+
+Профиль управления не заменяет схему привода 1×1/2×2 и назначения моторов.
+Последние определяют физические исполнительные устройства; профиль определяет
+смысл входных команд. Новые режимы не требуют повторной калибровки моторов.
+
+Уточнение владельца: при автономном движении или удалённом ручном управлении
+пульт может оставаться включённым и готовым к немедленному перехвату. Движение
+рычага за пределами проверенной нейтрали должно отбирать управление у всех
+источников Mission Core без переключения режима в интерфейсе. После перехвата
+нейтраль пульта не возобновляет прерванную задачу. Локальный оператор может
+освободить застрявший ровер даже при недоступном операторском Core; отказ самого
+Mini также не должен лишать его независимого RC-пути. Уведомления об аномалии
+и обнаружение застревания пока описывают будущий сценарий, не реализованный код.
+
+Следующее уточнение владельца: отдельный интерфейс переключения источника
+управления не нужен. Владелец наблюдает, что пульт работает только когда четыре
+верхних переключателя подняты, и предлагает использовать это как сигнал
+ручного перехвата. Наблюдение ещё не разделено на блокировку при включении и
+поведение уже работающего передатчика. По руководству FS-i6S, раздел 4.1,
+верхнее положение требуется при включении; раздел 2.2.3 описывает SwA–SwD как
+назначаемые переключатели. Документ не подтверждает отдельный передаваемый
+признак «все четыре подняты» или отключение радиолинка любым из них.
+
+Владелец затем исправил наблюдение: управление моторами сохраняется и со
+всеми четырьмя тумблерами в нижнем положении. Гипотеза «любая нижняя позиция
+выключает управление/радиосвязь» отозвана. Начальный пассивный замер был
+помечен заявленным положением SWA, но его нельзя использовать как доказательство
+влияния тумблера: синхронное сравнение состояний не завершено. Предложенное
+переключение SWA для следующего замера отменено. Проверка положений при
+включении остаётся вероятным объяснением, не подтверждённой настройкой пульта.
+
+Это требование к автоматическому выбору источника не отменяет ранее заказанную
+настройку Tank/Arcade: раскладка органов управления и право выдавать команду
+моторам — разные свойства. Перехват не должен требовать клика в Core.
+
+## Последнее уточнение: первый ввод останавливает, следующий управляет
+
+Владелец изменил непосредственную реакцию на RC: первый ввод с рычага должен
+только прервать автономное/удалённое движение; последующий ввод может управлять
+моторами. Отменяются задачи автономной езды и их вычислительные исполнители,
+включая связанные с ней inference/планирование/обработку облаков. Запрет на
+выходные команды должен вступать в силу раньше и независимо от завершения
+таких задач. Нельзя ждать остановки тяжёлого вычисления, прежде чем запретить
+ему движение; запоздавшие результаты и команды теряют допуск.
+
+Один удерживаемый рычаг создаёт непрерывную последовательность пакетов, поэтому
+«следующий пакет» не равен второму осознанному действию. Подтверждённая владельцем
+последовательность — первый выход из нейтрали: остановка; затем оба моторных
+канала в устойчивой нейтрали; затем новое отклонение: ручное движение.
+Ответ владельца 2026-09-24: «Да: остановка → нейтраль → управление».
+Требование принято; изменение рабочего моторного runtime ещё не выполнено.
+
+Для этой трактовки нужны состояния прекращения команд, подтверждения остановки,
+ожидания нейтрали и ручного управления. Нельзя пропускать первое удерживаемое
+отклонение после фиксированной паузы или считать перезапуск процесса разрешением
+движения. Проверяются свежесть входа, все назначенные стороны и отзыв старых
+допусков. Длительность нейтрали и допустимое время остановки задаются после
+выбора и проверки исполнительного механизма, не случайной константой.
+
+Текущая прямая PWM-проводка приёмник→VESC и истечение 250 мс аренды сами по себе
+не реализуют это требование: отпустив аренду при удерживаемом RC, программа
+передаст в мотор уже первое отклонение. Нельзя выдавать существующий test latch
+за stop-first. Также удержание блокировки только на Mini не гарантирует эту
+семантику при отказе Mini. Для независимой гарантии проверка перехода должна
+жить у исполнителя либо в отдельном независимом тракте; stock FW 5.02 такой
+квалифицированной функции в нынешней схеме не имеет. Это архитектурная граница,
+не разрешение автоматически прошивать VESC или покупать новый контроллер.
+
+Остановка вычислительных задач не означает остановку служб приёма RC,
+контроля привода и наблюдения его состояния. Нулевая команда тока не доказывает
+физическую остановку: выбег/торможение и допустимая рекуперация требуют отдельной
+проверки. Автоматический возврат к прерванной задаче после нейтрали запрещён.
+
+### Подтверждённая последовательность
+
+| Состояние | Событие | Требуемая реакция |
+| --- | --- | --- |
+| Движением управляет Mission Core | Первое допустимое отклонение любого назначенного RC-канала | Отозвать допуск всех остальных источников, очистить их очередь, начать согласованную остановку всех приводов и отменить задачи автономного движения. Первое отклонение не передавать как команду езды. |
+| Остановка / ожидание нейтрали | Рычаг остаётся отклонённым, приходят новые пакеты | Сохранять запрет движения; количество пакетов и прошедшее время сами по себе его не снимают. |
+| Остановка / ожидание нейтрали | Остановка подтверждена, все назначенные рычаги вернулись в подтверждённую нейтраль | Разрешить следующий осознанный RC-жест; Mission Core остаётся без допуска к движению. |
+| Пульт готов к движению | Новое отклонение рычага | Передать ручную команду назначенным приводам. |
+| Пульт управляет | Последующие отклонения и возвраты в нейтраль | Обычное ручное управление. Каждый новый жест не повторяет процедуру перехвата. |
+| Любое состояние после перехвата | Пришла запоздавшая команда отменённой задачи / восстановилась связь Core | Отклонить команду. Восстановление связи не возобновляет автономное движение. |
+
+Это контракт поведения, не таблица состояний установленной реализации.
+Условия свежести и нейтрали относятся ко всем назначенным каналам, независимо
+от схемы 1×1/2×2 и числа моторов. Пропавший канал не считается нейтральным.
+Ответ на USB-запрос с последним декодированным значением сам по себе не
+доказывает свежий импульс приёмника: FW 5.02 не возвращает его возраст в
+`COMM_GET_DECODED_PPM`. Нейтральный failsafe также не доказывает отпускание
+стика оператором. Эти ограничения должны быть учтены до допуска автономии.
+
+### Проверка штатной FW 5.02
+
+Аудит выполнен по сохранённому upstream commit
+`3f670137e27e6e383fa79c50cc6b1fa85aab1554`; Git blob-хэши `app_ppm.c`,
+`app.c`, `commands.c`, `datatypes.h` совпадают с сохранённым деревом Git.
+Это проверка исходников upstream, не доказательство побайтового совпадения
+прошивки производителя в имеющихся контроллерах.
+
+- `applications/app_ppm.c`: вход декодируется при отключённом выходе;
+  Safe Start использует счётчик нейтральных импульсов после конфигурации,
+  тайм-аута приёмника или ошибки. Ветка отключённого выхода не сбрасывает
+  этот счётчик. Завершение USB-аренды не создаёт новую проверку нейтрали.
+- `applications/app.c::app_disable_output`: положительное время отключает
+  выход до истечения таймера; его callback просто разрешает выход. Значение
+  −1 отключает бессрочно, что не подходит для независимого RC при отказе Mini.
+- `commands.c::COMM_SET_APPCONF`: перезапускает приложения и сохраняет
+  конфигурацию во flash. Это не команда ручного перехвата на каждый жест.
+- `COMM_SET_CAN_MODE` может вызвать тот же перезапуск без сохранения, но
+  перезапуск PPM/UART и других приложений через настройку CAN не является
+  проверенным механизмом передачи управления. Такой обход не применяется.
+- Наш native `release` отправляет `setCurrent(0)`: это снятие тяги, а не
+  подтверждённое торможение и не повторное включение Safe Start.
+
+Для исправного Mini возможен программный цикл удержания выхода до нейтрали.
+Он не обеспечивает одинаковое поведение при потере Mini/USB: таймер в VESC
+всё равно истечёт. Штатной проверенной функции для полного требования в
+текущем тракте не найдено. Нужна поддержка перехвата на исполнительном уровне
+либо другой независимый тракт. Простого изменения в одном VESC недостаточно:
+отклонение одного канала должно согласованно остановить весь борт, а топология
+межконтроллерной связи пока не подтверждена.
+
+Следующий этап реализации — выбрать и проверить такой механизм по имеющемуся
+железу, включая отзыв прямых USB-команд, согласование всех приводов, остановку
+и нейтраль при отказе Mini. Обновление/доработка прошивки требует отдельного
+плана совместимости и восстановления. Пока проверяются эти условия,
+не активировать автономное движение и не выдавать действующие стендовые
+тесты за принятый постоянный арбитр. Прошивки и рабочая RC-конфигурация в этом
+аудите не изменялись.
+
+Кандидат для следующей проверки без отдельного бортового контроллера —
+штатная LispBM-поддержка современных VESC: upstream документирует для FW 6.00+
+`get-ppm`, `get-ppm-age`, `app-ppm-detach`, `app-ppm-override`, а также доступ
+к PPM других VESC через настроенный CAN. Код исполняется в контроллере,
+не на Mini. Это возможный исполнитель подтверждённой последовательности,
+не готовая встроенная функция перехвата и не доказанная гарантия приоритета
+над прямыми USB-командами. Нужны проверка совместимости платы, согласованный
+обмен между приводами, исключение обхода арбитра, реакция на остановку скрипта
+и квалификация поведения при потере каждого соединения. Возраст PPM отличает
+отсутствие импульсов от их наличия, но не живой радиолинк от импульсов failsafe.
+Текущая версия 5.02 этой документированной LispBM-возможностью не подтверждена.
+Маркер 75_300_R2 недостаточен для выбора прошивки; у владельца запрошены
+производитель и точная модель, если известны. Обновление не запускалось.
+[Документация LispBM VESC](https://github.com/vedderb/bldc/blob/master/lispBM/README.md),
+[описание поддержки в FW 6.00 автором VESC](https://vesc-project.com/node/3385).
+
+## Что подтверждено
+
+Приёмник на прежней фотографии — FlySky FS-iA6B. По сообщению владельца,
+левый VESC подключён к CH3, правый к CH2. Принятое вращением назначение
+контроллеров хранится по UUID, независимо от USB-порта.
+
+Новые фотографии пульта показывают маркировку Robcom Venom Drone. Корпус,
+две кнопки питания, сенсорный экран, расположение переключателей, задних
+кнопок и PS/2/USB совпадают со схемой FlySky FS-i6S. Это обоснованная
+идентификация семейства по внешности. Владелец сообщает о втором внешне таком
+же пульте без маркировки Robcom. Последующий осмотр About 2026-09-25 подтвердил
+сообщаемые устройством Flysky FS-i6S, прошивку 2.00 от 04-Apr-2020 и Hardware
+V_3.0; подробности видеоподтверждения приведены ниже. Это не аудит возможных
+OEM-изменений электроники.
+
+По руководству семейства FS-i6S, разделы 2.2.3 и 6.8, SwA/SwB/SwC/SwD —
+назначаемые переключатели: их можно связать с дополнительным каналом или
+функцией передатчика. У каждого нет постоянного назначения «камера»,
+«ручной режим» или «аварийный стоп». На дополнительном канале передаётся
+значение, соответствующее положению; смысл ему задаёт принимающая система.
+Фактические назначения конкретного пульта ещё не прочитаны. Меню Aux. Channels
+показывает назначения дополнительных каналов; функции самого передатчика
+могут использовать переключатели отдельно (например Trainer Mode, раздел 7.3).
+Текущее подключение CH2/CH3 к VESC не даёт Mini доступ ко всем этим каналам.
+
+В архиве конфигураций после принятого общего теста оба входа VESC настроены
+как PPM Duty Cycle. Левый использует приложение PPM, правый — PPM and UART.
+Настройки отклика различаются: разгон/сброс слева 0,4/0,2 с, справа 0,5/0,5 с;
+параметр polynomial curve слева −1, справа −1,5; deadband у обоих 0,15.
+Это сохранённые значения, не новое чтение после текущей загрузки и не
+основание автоматически уравнивать параметры. Ровное вращение на общей
+команде ERPM не означает одинаковую реакцию на одинаковое положение стиков.
+
+У обоих сохранён multi_esc=true. Наличие и топология физического CAN ещё
+не подтверждены. Перед изменением схемы команд надо исключить взаимную
+пересылку между левым и правым бортом; одну настройку нельзя считать схемой
+проводки. Никакого CAN broadcast или изменения multi_esc сейчас не сделано.
+
+## Канонические механизмы
+
+В терминологии WPILib первый режим — Tank Drive, второй — Arcade Drive.
+Arcade преобразует движение и поворот в согласованную пару команд левой и
+правой стороны. Curvature Drive — отдельный вариант поведения поворота;
+его нельзя незаметно подменять под тот же профиль. Стороны могут включать
+несколько назначенных моторов. [Официальное описание WPILib](https://docs.wpilib.org/en/stable/docs/software/hardware-apis/motors/wpi-drive-classes.html).
+
+Микширование не должно трактовать ток как заданный радиус поворота: ток
+связан с моментом, а скорость зависит от нагрузки. Нормализация, насыщение,
+знаки, нейтраль, движение назад и разворот на месте требуют явной модели и
+приёмки. Микшер и ограничения мощности — разные части системы.
+
+Штатное приложение PPM прошивки VESC 5.02 читает один импульсный вход.
+multi_esc пересылает ту же команду другим контроллерам, а не вычисляет
+дифференциальное управление из двух осей.
+[Исходник FW 5.02](https://github.com/vedderb/bldc/blob/5.02/applications/app_ppm.c).
+
+В официальном руководстве FS-i6S есть Mix (master/slave, положительный и
+отрицательный коэффициенты), сохранённые модели и просмотр каналов. Число
+доступных независимых миксов, назначение осей и поведение их композиции в
+имеющейся прошивке ещё не проверены. Наличие пункта Mix не доказывает
+возможность получить два требуемых выхода на нынешних CH2/CH3. Меню About
+показывает модель и версии. Failsafe=Off в руководстве означает удержание
+последнего значения; выключенный передатчик нельзя приравнивать к нейтрали
+без измерения выхода приёмника. [Руководство производителя](https://www.flysky-cn.com/s/FS-i6S-User-manual-20200628-al4y.pdf), разделы 6.9, 6.10, 7.2, 7.13.
+
+## Где может исполняться профиль
+
+1. В пульте. Сначала проверить штатное микширование на экране каналов без
+   команд моторам. Такой путь сохраняет независимость от Mini. Через два
+   имеющихся PWM-провода Mission Core не может читать или менять модель
+   передатчика: нельзя показывать локально сохранённый выбор как применённый.
+2. На Node. Нужен полный вход с осями и явным выбором управления, например
+   через приёмник iBUS и совместимый интерфейс. Разъём iBUS есть у семейства
+   FS-iA6B, но соответствующего подключения к Mini сейчас не подтверждено.
+   Сначала проверить уровни, адаптер, формат и режим реального приёмника.
+   Текущих двух вертикальных осей недостаточно для правого двухосевого стика.
+3. Во внешнем контроллере/микшере. Это технический вариант, а не принятое
+   решение: владелец хочет обойтись существующим бортовым компьютером.
+
+Выбор пути зависит от наблюдаемой аппаратуры. Реализацию универсального
+переключателя нельзя завершить, скрыв эту зависимость. Не прошивать пульт или
+VESC и не переподключать каналы ради проверки гипотезы без отдельного плана.
+
+## Наблюдение входа и приоритет пульта: существующая граница
+
+Текущий native backend уже читает через VESC Tool `COMM_GET_DECODED_PPM`:
+декодированный уровень и длительность последнего импульса одного входа VESC.
+Два USB-соединения дают два подключённых канала приёмника. Это не полный
+радиообмен передатчика с приёмником, не все оси/переключатели и не подтверждение
+радиолинка. Штатный PPM-код продолжает декодировать вход при временно отключённом
+выходе приложения. Прямые команды тока/ERPM через USB уже применялись в тестах;
+воспроизведение радиопакетов или подмена PWM-проводов для этого не нужны.
+
+По двум нейтральным значениям CH2/CH3 нельзя различить включённый передатчик
+с отпущенными стиками и выключенный передатчик при нейтральном failsafe.
+Положения SwA–SwD тоже не следует выводить из этих значений. Для перехвата по
+переключателю нужен проверенный соответствующий канал, доступный на борту;
+для перехвата по наличию радиолинка — подтверждённый признак валидности связи.
+Подключение полного потока приёмника к Mini пока не подтверждено. Если сама
+готовность включённого пульта означает ручной режим, автономия с включённым
+готовым пультом блокируется; это отличается от предыдущего сценария перехвата
+движением рычага. До выяснения реального сигнала не менять рабочую схему.
+
+В `motor_test.py` и `group_test.py` проверка входа выполняется до следующей
+подачи команды. Активный канал записывает состояние `rc`, прерывает тест и
+запрещает новый запуск до явного `vesc.control.release` после нейтрали.
+`receiver.py` использует свежую конфигурацию deadband каждого VESC, а не
+считает любой ненулевой шум командой. Это действующий код коротких стендовых
+тестов, не принятый постоянный арбитр автономного движения.
+
+Тесты временно приостанавливают выход PPM отдельными продлеваемыми арендами
+по 250 мс. Таймер исполняется в VESC: при прекращении продления PPM возвращается
+без участия Mini. Это защита от исчезновения процесса/USB, а не гарантия
+приоритета RC при ошибочной программе, продолжающей продлевать аренду. Также
+250 мс не являются измеренной максимальной задержкой перехвата всего ровера.
+Надёжный постоянный тракт требует проверки таймаутов, возврата RC, отсутствия
+поздних USB-команд и поведения всех назначенных сторон. Гарантия при ошибочной
+программе на живом Mini потребует независимого решения у исполнительного
+уровня; наличия такой гарантии в stock FW 5.02 не установлено.
+
+Штатные FOC/Hall-процедуры FW 5.02 не прерываются обычной командой пульта.
+Они остаются отдельным сервисным режимом вывешенного привода и не могут
+запускаться в автономном движении под обещание постоянного RC-перехвата.
+
+## Контракт реализации в Mission Core
+
+- Один версионный профиль борта: режим, источник входа, проверенное назначение
+  осей, стороны/UUID, параметры отклика и ссылка на отдельные пределы привода.
+  Хранить желаемое и подтверждённое применённое состояние раздельно.
+- Общий интерфейс в существующем блоке через компоненты Design Guideline;
+  калибровка конкретного двигателя остаётся в карточке VESC.
+- Смена профиля только после нейтрали всех назначенных сторон. При частичной
+  потере связи запрещено объявлять общий профиль применённым.
+- Перехват пультом фиксируется до явного возврата управления. Нулевое значение
+  PWM само по себе не определяет, выключен передатчик или стоит в нейтрали.
+- На Node должен быть один владелец выхода: все команды автоматики, клавиатуры,
+  удалённого джойстика и другого управления проходят через него. Перехват RC
+  отзывает их допуск и отменяет очередь; опоздавшая команда старого допуска
+  не может вновь включить движение. Core отображает состояние, но не является
+  звеном, необходимым для локального перехвата.
+- Потеря Core, Node, входного потока или одного VESC должна иметь проверенное
+  поведение. Существующая аренда отключения PPM для коротких тестов не является
+  приёмкой постоянного удалённого управления. Без Mini должен сохраняться
+  понятный оператору независимый путь RC, а не внезапная смена смысла стиков.
+- Нативный VESC Tool остаётся владельцем протокола и конфигурации контроллеров;
+  калибровочные алгоритмы не копируются в новый модуль профилей.
+
+## Приёмка и порядок
+
+Node 0.8.38-2 установлен; Core принял оба VESC после исправления версии драйвера.
+
+1. Завершить диагностику существующего привода до установки гусениц:
+   подтвердить связь и сохранить свежие конфигурации; отдельно сравнить Холлы
+   левого и правого мотора без замены принятой калибровки. Перед процедурой
+   заново синхронизироваться с наблюдающим владельцем. Если сигнал отсутствует,
+   отделить неисправность проводки/датчика от недостаточности измерения.
+   Повторная калибровка не восстанавливает физический контакт.
+2. После результата проверить оба направления, старт и остановку, затем
+   поведение пульта при потере связи на вывешенном приводе. При необходимости
+   уточнить нейтраль и failsafe через штатные средства. Дать отдельный вывод
+   о готовности к ограниченной нагрузочной проверке; существующий ровный
+   тест без нагрузки и исправный правый Hall не доказывают исправность левого.
+3. Для нового управления прочитать About, меню Mix, карту каналов и failsafe
+   пульта без изменения рабочей модели. Проверить точную модель VESC и
+межконтроллерную связь. Недостающая модель не блокирует диагностику текущей
+   версии, но блокирует обоснованный выбор новой прошивки.
+4. Выбрать штатный исполнитель перехвата с независимостью от Mini, подготовить
+   версионную интеграцию и сначала проверить переходы без движения. LispBM
+   остаётся кандидатом; обновление не является обязательным следующим шагом
+   и не выполняется по одному имени 75_300_R2. Приёмка включает удержание
+   первого жеста, нейтраль всех входов, второй жест, запоздалые команды,
+   потерю Core/Mini/USB/связи между контроллерами и отсутствие самовозврата.
+5. Реализовать Tank/Arcade и общий профиль ограничений в существующих
+   «Настройках борта», с индивидуальными пределами каждого привода. Выбрать
+   место микширования по реально доступным каналам. Новые численные максимумы
+   и запас 20% требуют характеристик моторов, VESC и общей батареи/BMS;
+   приблизительные 500 Вт и имя аппаратной прошивки их не подтверждают.
+
+Испытание на гусеницах зависит от результата пунктов 1–2 и допустимых рабочих
+пределов, а не от завершения будущей автономии. Новый RC-перехват и Arcade
+проверяются на вывешенном приводе до проверки под нагрузкой.
+
+Уточнение владельца: идентифицировать контроллеры программно; разборка ровера
+ради чтения маркировки нежелательна и сейчас не требуется. В выполненном
+аудите через установленный native Tool оба контроллера подтвердили уникальные
+UUID, FW 5.02 / 75_300_R2, штатный тип VESC, test_firmware=0 и custom_configs=0.
+С каждого считаны полные motor/app-конфигурации (151/149 параметров), вход PPM
+и телеметрия. Оба штатных CAN ping дали пустой список: межконтроллерный обмен
+не подтверждён, но отсутствие физических проводов из этого не следует.
+USB-дескрипторы и USB-серийники одинаковы; идентичность по-прежнему задаёт
+UUID VESC. Новые резервные копии есть в истории Core и совпадают с принятыми
+архивами после калибровки. Движение и изменения настроек не выполнялись.
+
+Аппаратная сборка не определяет коммерческую модель: сам производитель
+[Flipsky описывает разные платы серии 75 на основе 75_300_R2](https://flipsky.net/blogs/vesc-tool/tips-of-75-serise-esc).
+Это подтверждение неоднозначности, не доказательство бренда имеющихся плат.
+Ни новый образ прошивки, ни паспортные пределы не выбираются по одному этому
+имени. Продолжить неразрушающую программную диагностику и использовать
+существующую комплектацию/документацию изготовителя ровера для свойств,
+которые текущий протокол не сообщает.
+
+Для выбранной реализации проверить нейтраль, прямое/обратное движение,
+повороты и крайние диагонали, одинаковую ограниченную реакцию сторон, переход
+между режимами в нейтрали, RC-перехват и отказ каждого канала связи. Сначала
+без движения (преобразование входов), затем на вывешенном приводе; нагрузочные
+испытания и настройка поворота на гусеницах — отдельный этап. Успешный тест
+без нагрузки не подтверждает старт под нагрузкой с повреждённым Холлом.
+
+
+## Comparative Hall result, 2026-09-24 12:13 UTC
+
+Node 0.8.39-1 / plugin 0.6.6 completed both separate canonical measurements.
+LEFT again yields only [1,3,5,7] while the owner observes movement both ways;
+RIGHT yields [1,2,3,4,5,6] and firmware success. Both configurations are unchanged
+and current release is confirmed. Hall diagnostic localization is complete:
+LEFT circuit incomplete, RIGHT six-state signal accepted. Exact broken physical
+contact is not identified and no hardware repair is claimed. Sensorless LEFT
+versus Hall RIGHT operation remains. The owner next requests visible sustained
+rotation in both directions; this is a bench-test feature, separate from RC
+Tank/Arcade profiles and the stop → neutral → manual authority contract.
+
+## Прототип во время отсутствия владельца
+
+По прямому запросу владельца подготовлены `packages/rover-control/src/profile.ts`
+и `authority.ts`: расчёт Tank/Arcade, UUID-назначения произвольного числа моторов,
+версионный JSON желаемого профиля и модель stop → neutral → manual. В production
+runtime они не подключены. 21 направленный тест проверяет знак и пределы
+смешивания, 2/4/10 моторов, первый/второй жест, непрерывную нейтраль, потерю
+любого привода/приёмника, устаревшие данные, часы, команды и допуски после reboot.
+Оси для перехвата объявляются отдельно от осей микшера: в макете даже второй
+рычаг останавливает Core в Arcade, а пропавшая ось не считается нейтралью.
+
+Отдельный макет `apps/control-station/tools/rover-control-preview` использует
+канонические контролы Design Guideline, показывает расчёт и сохраняет/выгружает
+черновик. Сеть запрещена CSP; никакого обращения к роверу или новой продуктовой
+вкладки нет. Пороговые времена в моделировании — синтетические, не приёмка
+времени остановки Rover006. Алгоритмы калибровки VESC Tool не копировались.
+Контракт и ограничения: [rover-control README](../../packages/rover-control/README.md).
+
+## Текущий пульт: приёмка потери сигнала завершена
+
+2026-09-24 владелец прочитал Failsafe: CH1…CH10 показывают 0%. После отдельной
+проверки каждого мотора с удерживаемым рычагом и извлечением батарейки пульта
+владелец подтвердил остановку обоих. Возврат питания/радиосвязи с рычагами
+в центре не вызвал движения. Журналы, ограничения измерений и отличие от
+непринятого первого опыта записаны в [протоколе 24](24_RC_FAILSAFE_ACCEPTANCE.md).
+Рабочие конфигурации не менялись; это приёмка существующего прямого RC-пути,
+не новой логики перехвата. Можно продолжать чтение Functions → Mix и карты
+каналов. Подтверждение аппаратного исполнителя профилей в Core остаётся
+обязательным до их активации: один переключатель в UI не меняет проводку.
+
+## Сохранённые настройки пульта: осмотр 2026-09-25
+
+Владелец последовательно прочитал и затем явно подтвердил весь список: всего
+четыре правила Mix, номера 1/3/4 выключены, только Mix 2 включён. Параметры
+Mix 2: Master C3, Slave C4, Offset 0%, NEG −100%, POS −100%. Это перечень
+правил внутри текущей модели, не четыре взаимоисключающих профиля ровера.
+Настройки не меняли. Назначение C4 в конструкции пока не установлено; по
+сообщённой проводке моторные входы подключены к CH2/CH3. Нельзя приписывать
+этому миксу управление вторым мотором без проверки всей карты каналов.
+
+Владелец прислал видеозапись меню продолжительностью около 74 секунд.
+Выполнен локальный визуальный разбор кадров; исходное видео не изменено,
+аудиодорожка не транскрибировалась. Закрытый manifest с SHA-256 исходника,
+методом разбора и кадрами хранится вне репозитория в
+`outputs/rover-006-tx-menu-review-20260925/manifest.json` корня рабочего пространства.
+Время ниже приблизительное, это не измерение задержки управления.
+
+| Экран | Наблюдение |
+| --- | --- |
+| Монитор каналов, 8–13 с | Полосы CH1…CH6, затем прокрутка. Отдельных движений осей с одновременным наблюдением каналов нет. |
+| Reverse, 21–23 с | CH9 — Rev; остальные показанные каналы CH1…CH10 — Nor. |
+| End points, 28 с | CH2: 100/110%; CH3: 110/100%, в порядке двух столбцов экрана. Это диапазон сигнала пульта, не проценты мощности или тока VESC. |
+| Subtrim, 33–36 с | Видимые значения 0%. |
+| Trims, 40–42 с | Off. |
+| Rate/Exp., 45–47 с | Только показанный CH1 Normal: Rate 100, Exp. 0. Значения других каналов не проверены. |
+| Rate/Exp. switch, 50–51 с | Assign SW: Null. |
+| Throt curve, 56–57 с | График визуально прямой; численные значения всех точек не открывались. |
+| Aux. channels, 60–62 с | Channel 5 назначен SwA. Назначения SwB/SwC/SwD ещё не прочитаны. |
+| Failsafe, 66–67 с | CH1…CH10 показывают 0%, согласуется с предыдущим чтением и принятой проверкой потери связи. |
+
+SWA → CH5 подтверждает назначаемую функцию переключателя в текущей модели,
+но не доступ Mini к этому каналу и не аварийную остановку. Монитор каналов
+найден; повторно искать его или перебирать Mix не требуется. Следующее чтение
+— системные Sticks Mode, Output Mode и About: установить раскладку, режим
+выхода и версию устройства без изменения модели. Фактическое соответствие
+осей выходам затем проверяется отдельно; этот ролик его не доказывает.
+Никаких команд аппаратуре или изменений приложения при разборе видео нет.
+
+## Системные меню и идентификация пульта, 2026-09-25
+
+Вторая запись владельца, около 77 секунд, содержит экран About на 72–74 с:
+Flysky FS-i6S, версия 2.00, дата 04-Apr-2020, Hardware V_3.0. Идентификация
+пульта теперь опирается на его собственный экран, а не только на форму корпуса.
+Это не идентификация VESC и не повод обновлять прошивку пульта или моторов.
+
+Trainer Mode показан OFF, Switch Null; Student Mode показан OFF. Попытки
+открыть Output Mode (около 22 с) и Sticks Mode (около 25 с) останавливаются
+сообщением `Turn off RX!`. Значения режима выхода и раскладки рычагов не
+открылись, поэтому нельзя объявлять Mode 2 либо конкретный PWM/iBUS режим
+прочитанными. RX здесь означает приёмник; повторное нажатие OK при работающем
+приёмнике не раскрывает заблокированные настройки. Для чтения нужен штатно
+обесточенный приёмник при оставленном включённым передатчике, без изменения
+значений или обхода блокировки. Никакого отключения во время разбора не было.
+
+Закрытое подтверждение с SHA-256 исходника и пятью кадрами:
+`outputs/rover-006-tx-system-review-20260925/manifest.json` корня рабочего
+пространства. Видеофайл неизменён, аудио не транскрибировалось; просмотр кадров
+не является проверкой движения или записью конфигурации. Не запускать
+Sticks Adjust, Factory Reset, RX Bind или Firmware Update ради чтения профиля.
+
+## Ограничение комплектации: без нового подключения приёмника, 2026-09-25
+
+Владелец явно исключил подключение FS-iA6B к Mini дополнительными проводами,
+адаптером или пайкой: таких средств нет, этот вариант сейчас неприемлем.
+Прямой вход iBUS/PPM в Mini не включать в обязательный текущий план. Он не
+нужен для уже доказанного управления VESC по USB: оба существующих тракта
+сохраняются — пульт → приёмник → моторный вход VESC и Mini → USB → VESC.
+Через VESC доступны два подключённых входных канала; полный поток остальных
+осей и переключателей от этого не появляется.
+
+Наличие двух рабочих путей не означает приёмку их одновременных конкурирующих
+команд. Нынешний код ограниченных тестов временно удерживает выход PPM,
+продолжает читать вход и прекращает тест при RC-команде. Это не готовая
+постоянная логика «первый жест — остановка, нейтраль, второй жест — ручное
+управление» с гарантией при отказе Mini. Требование владельца сохраняется;
+нельзя объявлять его выполненным либо обещать независимую гарантию только
+потому, что USB-команды и прямой пульт по отдельности проверены.
+
+Продолжать аудит штатного микшера пульта и исполнительных возможностей VESC
+в имеющейся комплектации. Реализуемость Arcade на существующих моторных
+выходах, переключение его из Mission Core и независимый перехват — отдельные
+вопросы. Чтение меню пульта не доказывает дистанционную запись его профиля.
+Если точное требование недостижимо в этой комплектации, описать конкретное
+ограничение владельцу, не подменяя задачу профилем только для команд Core.
+
+## Разблокированные меню после отключения батареи, 2026-09-25
+
+Владелец прислал ещё две записи, около 66 и 32 секунд, с отключённой, по его
+сообщению, батареей ровера. Системные страницы теперь открываются. Прочитаны:
+
+- Models: Model 1.
+- Output Mode: выбран PWM; отдельный Serial: выбран i-BUS. Наличие выбранного
+  i-BUS не означает подключение этой линии к Mini; существующие VESC получают
+  отдельные каналы PWM. Проводка остаётся прежней.
+- Sticks Mode: первоначально M2; на 37-й секунде первого ролика видно
+  переключение в M1, затем на 38–39-й — возврат в M2 до выхода со страницы.
+- Базовые назначения M2 до миксов: правый горизонтальный CH1, правый
+  вертикальный CH2, левый вертикальный CH3, левый горизонтальный CH4.
+  Включённый Mix 2 добавляет зависимость итогового CH4 от CH3; нельзя называть
+  его выход независимым сырым значением левой горизонтальной оси.
+- Throt Mode: Self centering.
+
+Это подтверждает, что для правого Arcade требуются две оси CH1/CH2, тогда как
+нынешние моторные подключения CH2/CH3 дают два вертикальных канала. Прямые
+команды Mini по USB остаются доступным независимым путём. Штатное микширование
+нужно проверять по фактическим выходам CH2/CH3, включая подавление ненужной оси,
+знаки, нейтраль, насыщение и сохранение рабочего Tank. Руководство описывает
+парный Master/Slave, но не доказывает конкретный порядок каскадирования миксов
+и кривых; схему нельзя объявлять рабочей только по формуле или числу слотов.
+
+### Новая проверка перед возвратом к движению
+
+На 48-й секунде первого ролика открыт Sticks Adjust. До конца записи нет
+полного прохода всех осей/крутилок по пределам; второй ролик начинается уже
+в обычном меню. Завершение процедуры между роликами не видно. По штатному
+руководству §7.8 это калибровка аналоговых органов пульта, с сохранением через
+выход после центрирования, а не обычный монитор каналов. Нельзя гарантировать
+неизменность калибровки или объявлять её испорченной по этим кадрам.
+
+Перед повторным включением силового питания нужен обычный монитор CH1…CH6
+с проверкой нейтрали и отдельных полных ходов осей при выключенных приводах.
+Это проверка пульта, не повторная FOC/Hall-калибровка VESC. Не использовать
+Sticks Adjust для чтения показаний и не запускать автоматический sweep.
+
+В первом ролике также кратко открыт RX Bind при выключенном, по сообщению
+владельца, приёмнике; результат привязки не проверялся. Во втором открыт
+диалог Factory Reset: нажата правая кнопка и выполнен возврат в меню; нет
+подтверждения выполненного сброса. Firmware Update просмотрен до страницы
+Continue, затем закрыт; обновление на записи не запускалось. Не превращать
+обход меню в утверждение, что все действия были только чтением.
+
+Закрытые оригинальные хэши, кадры и метод разбора:
+`outputs/rover-006-tx-offline-review-20260925/manifest.json` корня рабочего
+пространства. Оригиналы не изменены, аудио не транскрибировалось. Со стороны
+ассистента операций с пультом, Node или VESC при разборе не выполнялось.
+
+## Проверка монитора каналов после Sticks Adjust, 2026-09-25
+
+Следующая запись владельца, `IMG_2491.MOV`, около 41 секунды, показывает
+обычный монитор CH1…CH6 и движения сначала левого, затем правого рычага.
+Оба используемых моторных канала проходят в положительную и отрицательную
+сторону: CH3 при вертикальном движении левого рычага, CH2 — правого. После
+возврата рычагов значения визуально близки к центру, с небольшими остаточными
+смещениями. Признаков застрявшего крайнего значения или отсутствующей половины
+хода этих двух каналов в записи нет. По полоскам нельзя измерить точные
+проценты, ширину PWM-импульса или подтвердить допустимую нейтраль на VESC.
+
+Горизонтальные движения изменяют CH4 слева и CH1 справа; часть правого
+горизонтального прохода затемнена/перекрыта рукой. Зависимость CH4 от
+вертикального CH3 имеет противоположный знак и соответствует ранее прочитанному
+Mix 2. Неподвижное пятно на поверхности экрана возле CH4 не является показанием
+канала. Это качественная проверка раскладки M2 и моторных выходов пульта,
+не приёмка Arcade, нового перехвата, радиосвязи или failsafe после изменения
+меню. Повторное обследование меню для установления этих назначений не требуется.
+
+Следующий шаг после подтверждённого владельцем возврата питания на вывешенном
+ровере с рычагами в центре — прочитать фактические уровни обоих входов через
+VESC и сравнить их с сохранённой мёртвой зоной, без команд вращения. Во время
+разбора этого видео силовое питание не включалось средствами ассистента,
+команды приводам не отправлялись, калибровка VESC не менялась.
+
+Закрытые хэш исходника, 11 кадров и метод разбора:
+`outputs/rover-006-tx-axis-review-20260925/manifest.json` корня рабочего
+пространства. Оригинал не изменён; аудио не транскрибировалось.
+
+Продолжение: владелец вернул питание, проверил движение от стиков, затем
+подтвердил нейтраль и физическую остановку обоих моторов. Чтение через VESC
+подтвердило уровни справа −0.06, слева +0.068…+0.07 внутри deadband ±0.15,
+нулевые duty/ток батареи и отсутствие ошибок. Motor/application конфигурации
+обоих контроллеров побайтно совпадают с сохранёнными 2026-09-24. Проверка
+нейтрали после просмотра меню закрыта; подробности и границы результата —
+в `24_RC_FAILSAFE_ACCEPTANCE.md`, раздел «Нейтраль после возврата питания».
+Профиль одного стика и постоянный перехват этим чтением не приняты.

docs/node/24_RC_FAILSAFE_ACCEPTANCE.md

@@ -0,0 +1,247 @@
+# Приёмка пульта и потери сигнала
+
+Состояние: оба моторных канала прошли наблюдаемый вывешенный тест остановки
+при потере питания передатчика. Восстановление связи с рычагами в нейтрали
+не вызвало движения. Точное время реакции и поведение под нагрузкой не измерены.
+Node 0.8.40-1, VESC plugin 0.6.7, FW 5.02.
+Калибровка и рабочие настройки не изменяются этим исследованием.
+
+Обновление 2026-09-25: после просмотра системных меню передатчика и захода
+в Sticks Adjust повторно проверены монитор каналов, физическая остановка по
+сообщению владельца и фактическая нейтраль на обоих VESC. Конфигурации VESC
+побайтно совпадают с исходными от 2026-09-24. Это не повторный тест потери
+радиосвязи после действий с меню пульта; его прежняя приёмка относится к
+описанным ниже испытаниям 2026-09-24.
+
+## Начальное состояние, 2026-09-24
+
+Владелец подтвердил: пульт выключен, оба мотора неподвижны, гусеницы сняты,
+ровер вывешен. Свежая инвентаризация Core подтверждает два прежних UUID,
+нет активного теста или RC-защёлки. Через штатные операции сохранены обе
+конфигурации и прочитаны входы/телеметрия. Никаких команд движения, аренды
+выхода, alive, записи конфигурации или прямого доступа к serial не выполнялось.
+
+Оба контроллера: вход PPM около +0.010…+0.012 при deadband 0.15, PWM 0,
+ток батареи 0, fault 0. Правый показывает 0 ERPM. Левый при физическом
+покое показывает -153…-165 ERPM: ранее установленный дрейф бессенсорной
+оценки, не доказательство движения.
+
+Сохранённые настройки: duty-cycle PPM control; Safe Start включён; timeout
+1000 мс, timeout brake current 0 A; pulse 1.0/1.5/2.0 мс; multi_esc включён.
+Слева PPM, справа PPM+UART. Плавность слева 0.4 с набор / 0.2 с сброс,
+справа 0.5 / 0.5 с. Экспонента -1.0 слева и -1.5 справа. Из этого нельзя
+делать вывод о дефекте мотора или автоматически унифицировать настройки.
+
+## Граница измерения
+
+Декодированный PPM в FW 5.02 сообщает последнее значение и длину импульса,
+но не возраст импульса и не состояние радиолинка. Нейтраль при выключенном
+передатчике сама по себе не доказывает failsafe: передатчик мог быть выключен
+после нейтрали, а приёмник мог удержать последнее значение.
+
+По исходникам pinned upstream 3f670137: при утрате импульсов PPM обработчик
+проверяет их возраст и тайм-аут, снимая тягу при timeout brake current 0.
+Это не активное торможение с заданным временем остановки. Если приёмник
+продолжает выдавать ненулевое последнее значение, тайм-аут VESC не решает
+потерю радио. Руководство FS-i6S 2020-06-28, раздел 6.10, описывает Off как
+удержание последнего значения. Точная модель/настройка имеющегося передатчика
+ещё требует проверки его экрана; внешний вид не достаточен.
+
+## Порядок продолжения
+
+1. Включение пульта с обоими рычагами в нейтрали; чтение входов и наблюдение
+   отсутствия самопроизвольного движения.
+2. Чтение About, Failsafe для CH2/CH3 и карты каналов на пульте; без изменения
+   текущей модели. Если выявлено удержание последнего положения, сначала
+   подготовить и проверить нейтральный failsafe через штатные средства.
+3. Под наблюдением владельца проверить отклонение/возврат каждого рычага,
+   соответствие стороне и исчезновение команды в нейтрали.
+4. Отдельно согласовать выключение передатчика во время ограниченного
+   движения, прочитать вход и состояние обоих VESC, получить физическое
+   наблюдение остановки. Возвращать радиосвязь с рычагами в нейтрали.
+5. Проверить восстановление связи и отсутствие самопроизвольного движения.
+
+Чтение через отдельные удалённые операции даёт около 4.8 с на полный цикл
+двух входов и двух телеметрий в начальном замере. Такой журнал фиксирует
+состояния, но не позволяет подтвердить миллисекундную задержку остановки.
+Не выдавать USB-время ответа за время реакции радиоканала. При необходимости
+точного времени добавить продуктовую бортовую запись, не обходить драйвер.
+
+Исходный приватный протокол rc-failsafe-d83b84fb311245e5b8a3fea31716416b.json,
+SHA-256 8098fe14a754622cb027472fa4f48f96fa9ffcb0548b16af557ac90a56ea6fb1.
+Два полных цикла чтения, оба успешны. Наблюдатель rc_failsafe_observe.py
+разрешает только input.read, telemetry.read и config.backup.
+
+## Уточнение наблюдения после включения пульта
+
+Протокол rc-failsafe-34b93f7184024d87a8e66327f2f60649.json был изначально
+помечен `tx-on-neutral-confirmed`, но во время чтения зарегистрированы
+отклонения входов и вращение правого. Владелец уточнил: «Двигал рычаги;
+сейчас оба стоят». Поэтому этот замер содержит ручное управление и **не**
+является ни доказательством самопроизвольного запуска, ни чистой проверкой
+включения в нейтрали. Исходная метка и сырой протокол сохранены неизменными.
+SHA-256: 26dd21ffae833b4ac13aa1ceb004b97a3b58de8ea4ded9856ec616a335744d4b.
+
+Следующее чтение rc-failsafe-ea478fad45c047db919f892c23a34dc2.json подтвердило:
+справа вход −0.064 / 1.468 мс, слева +0.074 / 1.537 мс; оба в текущей зоне
+нейтрали ±0.15. На обоих PWM 0, ток батареи 0, fault 0. Справа ERPM 0,
+слева −156 при подтверждённом физическом покое — известная бессенсорная
+оценка. Это не подтверждает исправность левого Холла и не измеряет failsafe.
+SHA-256: 6fe3cceeae8d1afc6116048df9079001a46a1f08a8813de4782ac7433d33dab8.
+
+Владелец отошёл на 15 минут и разрешил независимую разработку/прототипирование.
+Моторные испытания приостановлены до его возвращения и новой синхронизации.
+Вопрос о модели в About и текущем Failsafe CH2/CH3 остаётся без ответа;
+повторно спрашивать или самостоятельно менять настройки по догадке не нужно.
+
+## Возвращение владельца
+
+Владелец сообщил: гусеница снята, пульт включён, он рядом и готов выполнять
+действия. Запрошено оставить рычаги в нейтрали и прочитать Failsafe CH2/CH3.
+До ответа выполнены только два цикла input.read/telemetry.read: справа вход
+−0.064…−0.066, слева +0.072…+0.074; оба в текущей зоне нейтрали. PWM и ток
+батареи 0, fault 0 на обоих; справа ERPM 0, слева −159…−151 (прежняя
+бессенсорная оценка, не отдельное подтверждение физического покоя).
+Протокол rc-failsafe-b05818b1cf8a426f8dccd5e6f80b19a5.json,
+SHA-256 511257aafc9d2f000d65073438399b9f7fa52c86515f4a7e994fd28b610737bb.
+Команд движения, alive, аренды выхода или записи конфигурации не было.
+
+## Экран Failsafe и первый ручной тест потери сигнала
+
+Владелец открыл сенсорное меню Functions после разблокировки экрана и затем
+Failsafe. Сообщил: каналы CH1…CH10, везде 0%. По официальному руководству
+семейства FS-i6S числовая позиция означает заданное положение при потере
+радиосигнала, в отличие от Off/удержания последней команды. Отдельные
+настройки не изменялись. Модель/версия из About ещё не прочитана.
+
+Для проверки выдано задание: на вывешенном приводе с демонтированной
+гусеницей запустить правый мотор небольшим отклонением, выключить пульт до
+возврата рычага, затем отпустить его; сообщить наблюдение остановки. Если
+вращение продолжается — вернуть рычаги в нейтраль и восстановить пульт.
+Программа при этом только читала входы и телеметрию, 13 циклов за примерно
+60 секунд. Зафиксированы правый вход +0.254, 798 ERPM и PWM 0.051; затем
+PWM 0, 72 ERPM, и в последнем цикле вход −0.064, PWM 0, ERPM 0. Fault 0
+на обоих VESC. Пары input/telemetry снимаются последовательно, не синхронно.
+
+Протокол rc-failsafe-fe6aea514466484aad007568c9f90cc0.json,
+SHA-256 d1c471f855f80c1715578df0bfc0e69a8c517a7cc9c2cf1aeaa09ef61e37c9a9.
+Физический результат и факт выключения при удерживаемом ненулевом рычаге
+пока ожидаются от владельца. До этого переход нельзя объявлять принятым
+failsafe; USB-наблюдение не отличает потерю радиосвязи от отпускания стика.
+Никакого испытания левого канала или восстановления радиосвязи ещё не принято.
+
+Уточнение владельца к первому тесту: он **сначала отпустил рычаг**, затем
+вынул батарейку пульта. Поэтому этот опыт не подтверждает остановку из-за
+потери радиосвязи. После снятия питания передатчика отдельное чтение показало
+правый вход +0.010 / 1.504 мс, левый +0.012 / 1.506 мс; PWM и ток батареи 0,
+fault 0 на обоих, ERPM правого 0. Протокол
+rc-failsafe-f99b5bb25bff471dbe017ed0b8f4632b.json,
+SHA-256 4ade3d8a2061048c67b3e21a83304fd6a9cb832942189f6a08c29792a6984adc.
+Это подтверждение нейтрального выхода при выключенном пульте после нейтрали,
+а не проверка прекращения ненулевой команды. Запущена отдельная запись для
+повтора с явным удержанием рычага до физического отключения передатчика.
+
+## Правый канал: остановка при потере радио подтверждена
+
+Повтор rc-failsafe-b208d87fa223496ca5fffebddf4ad9be.json, 25 полных циклов,
+2026-09-24T13:39:31.281029Z…13:41:33.274243Z,
+SHA-256 00e64109018c8b815b96b5db1e69fbb32ca7ab80bd8eff672f3ac86b69caffb1.
+После восстановления пульта вход правого вышел из нейтрали, зарегистрировано
+вращение. На цикле 11 вход +0.232 / 1.616 мс, 282 ERPM, PWM 0.022;
+на цикле 12 вход +0.010 / 1.505 мс, ERPM 0, PWM 0. Левый вход также
+вернулся к прежнему значению выключенного передатчика, PWM 0. Fault 0 везде.
+
+Владелец подтвердил: он вращал правым рычагом, вынул батарейку, и мотор
+остановился непосредственно при её извлечении. Это исправленный повтор
+предыдущего опыта с отпусканием рычага до отключения. Для правого канала
+поведение прекращения ручной тяги при потере радиосвязи принято в рамках
+этого вывешенного теста. Точная задержка в миллисекундах не измерена;
+нагрузочный тормозной путь и будущий stop-first перехват из Core не проверены.
+
+Следующий запуск записи для левого был случайно прерван владельцем. Проверено:
+нового протокола не создано, процессов rc_failsafe_observe.py не осталось.
+Команд движения не было. После возобновления запущен отдельный read-only
+протокол левого и выдана та же последовательность удержания рычага до
+отключения. Его результат пока ожидается; приёмка левого не следует из правого.
+
+## Левый канал: физическая остановка подтверждена владельцем
+
+Протокол rc-failsafe-cc289f6fce514a21af66bf7c17117e59.json завершён,
+24 полных цикла; SHA-256
+64164b2083a1b28172ebe1471a7f59df88c1d10b085db6e204f7c60f81608d11.
+На цикле 8 левый вход +0.280 / 1.640 мс, ток мотора 2.39 A; на цикле 9
+вход +0.012 / 1.506 мс, ток 0.04 A. После отключения оба PWM нулевые,
+fault 0. Сама скорость вращения левого не попала в редкие последовательные
+USB-замеры; его отрицательный ERPM при PWM 0 нельзя трактовать как движение.
+
+На отдельный прямой вопрос «Левый мотор действительно крутился до извлечения
+батарейки и остановился именно после него, пока рычаг оставался отклонённым?»
+владелец ответил «Да, крутился и остановился после извлечения». На основании
+этого физического наблюдения и записи возврата входа в нейтраль поведение
+левого канала при потере радио принято для данного вывешенного теста.
+Точное время остановки, нагрузка и исправность Холла этим не подтверждаются.
+Далее запущена отдельная запись восстановления пульта в нейтрали обоих рычагов.
+
+## Восстановление связи и итог
+
+Протокол rc-failsafe-6811a6865139462cb233566fb2bead05.json завершён,
+13 полных циклов; SHA-256
+c9d36bf24ca7ae43bb51bd7777c936e58ca44f3dd3d3b3b14126f6cf8717516f.
+В ходе записи входы перешли от значений выключенного пульта около +0.01
+к его включённой нейтрали: справа −0.062…−0.064, слева +0.076. PWM 0,
+ток батареи 0 и fault 0 на обоих во всех записанных циклах. Правый ERPM 0;
+слева прежняя ненулевая бессенсорная оценка при снятой тяге.
+
+Владелец подтвердил: после возврата батарейки, включения и ожидания около
+пяти секунд с рычагами по центру оба мотора остались полностью неподвижны.
+Приёмка текущего RC-пути в объёме стендового сценария завершена:
+ненулевая ручная команда → полное отключение передатчика → остановка отдельно
+справа и слева; затем восстановление связи в нейтрали без самопроизвольного
+движения. Источник физического результата — наблюдение владельца; журналы
+фиксируют входы/телеметрию с последовательным USB-опросом, а не точную задержку.
+
+Конфигурации и калибровка не изменялись, команды движения от Core не выдавались.
+Этот результат не принимает новый stop → neutral → manual перехват из
+автономии, отказ Mini/USB, поведение восстановления с отклонённым рычагом,
+нагрузочный тормозной путь или исправность повреждённой левой цепи Холла.
+Следующий этап — чтение текущих Mix/карты каналов пульта для Tank/Arcade,
+без изменения рабочего радиопрофиля по догадке.
+
+## Нейтраль после возврата питания, 2026-09-25
+
+После видеопроверки монитора передатчика владелец вернул питание ровера и
+сообщил, что моторы вращаются от стиков. Перед чтением отдельно подтвердил:
+пульт включён, оба стика по центру, оба мотора полностью неподвижны. Через
+канонический Core выполнены config.backup обоих VESC и два последовательных
+цикла input.read / telemetry.read. Тестов вращения, аренды выхода, alive и
+записи конфигураций не было. Оба прежних UUID в свежей инвентаризации доступны,
+активных моторных тестов нет.
+
+| Измерение | Правый | Левый |
+| --- | --- | --- |
+| Уровень декодированного входа | −0.059999 | +0.068…+0.069999 |
+| Импульс | 1.470 мс | 1.534…1.535 мс |
+| Настроенная зона нейтрали | ±0.15 | ±0.15 |
+| Duty / ток батареи / fault | 0 / 0 / 0 | 0 / 0 / 0 |
+| ERPM | 0 | −162…−147 |
+
+Оба входа внутри мёртвой зоны. Ненулевая бессенсорная оценка ERPM слева при
+нулевом выходе и подтверждённом физическом покое не является вращением.
+Сырые показания тока мотора справа −0.55…−0.79 A, слева +0.09…+0.11 A;
+не подменять их утверждением, что все датчики показывали математический ноль.
+Проверка нейтрали завершена; изменение deadband или повторная калибровка VESC
+по этим результатам не требуется. Полный цикл чтения занимает около 6 секунд
+и не измеряет задержку перехвата.
+
+Прочитанные motor/application payload каждого контроллера побайтно равны
+исходным из протокола `rc-failsafe-d83b84fb311245e5b8a3fea31716416b.json`.
+Рабочая FOC-калибровка, режимы sensorless/Hall, направление, токовые пределы
+и настройки PPM сохранены. Это сравнение конфигураций VESC, не всей модели
+или внутренней калибровки передатчика.
+
+Приватный протокол `rc-failsafe-b79d96f465f94fcb881e48a536ea0cc7.json`,
+SHA-256 `c71b9c4b805f9b7a0909e8a26355297a831224997f7cb0fd908ce08bf88960eb`.
+Отдельный результат сравнения:
+`rc-neutral-comparison-b79d96f465f94fcb881e48a536ea0cc7.json` в той же закрытой
+папке `outputs/rover-006-vesc-context-20260923/native-probe`. Наблюдатель
+завершился штатно; постоянный процесс опроса не оставлен.

docs/node/25_OBSERVATION_AND_REMOTE_CONTROL.md

@@ -0,0 +1,545 @@
+# Observation and remote control — implementation record
+
+Owner request: 2026-09-25. Extend the existing per-vehicle observation center.
+The operator sees cameras, map, a vehicle model and per-controller telemetry,
+then explicitly takes keyboard/pointer control. Return goes to the vehicle list.
+
+## Product surface decision
+
+Selected: two new layers in the admitted observation composition, with the model
+below the map and telemetry alongside it. Rejected: a separate driving workspace,
+which would separate the operator from cameras and duplicate vehicle navigation.
+No primary navigation or product root changes. Layer visibility/order/splits stay
+in the existing versioned per-vehicle layout. The header host owns the back action.
+
+States: offline, observing, preparing, ready, driving, receiver takeover, stopped,
+fault. Showing a model, pressing a key while disarmed, or reconnecting never arms
+motion. Stale telemetry is unavailable, not zero. No fabricated position/distance
+or model motion is inferred from keyboard intent.
+
+Design Guideline: existing Button/IconButton/Window/Select/Switch/LoadingRegion,
+SplitPane, GlassSurface and StatusBadge. Owner explicitly approved outlined
+momentary key buttons; shared KeyButton is added to DG first. Arcade W/S+A/D;
+tank Q/A left forward/reverse, E/D right forward/reverse. Space stops/disarms.
+
+## Sources
+
+NodeDC source: `NODEDC_ENGINE_INFRA/nodedc-source/src/viewer/playcanvas/`.
+Copy the rendering implementation, DEFAULT_POSTFX and environment atlas with
+source hashes; keep lighting/postprocessing/grid shader settings unchanged.
+Vehicle export preserves immutable Blender originals. v021 is a two-scheme
+kinematic study, not the full rover; full reconstruction is v020. Owner explicitly selected v020. The export contains all 1,426 renderable
+objects, joined into four donor material groups without geometric decimation.
+
+## Control boundary
+
+Existing five-second inventory/operation heartbeat is unsuitable for held keys.
+Implement a separate authenticated, ephemeral command channel on the already
+paired mTLS transport. Core does not access USB. The Node relays to its single
+VESC owner. Browser, relay and native output each have bounded leases; commands
+are identity/session/sequence bound and never persist or resume after restart.
+Motion command transport is distinct from configuration/calibration operations.
+Per-wheel current is measured motor current; battery input current is separate.
+
+Stock FW 5.02 resumes direct PPM when its output-disable lease expires. A healthy
+board can stop on RC intent and require neutral; a failed board cannot guarantee
+the full first-gesture-stop protocol against held RC input. This limitation must
+remain explicit in acceptance and cannot be fixed by UI promises.
+
+## Validation — 2026-09-25
+
+Core lease tests: 13 passed. VESC driver: 127 tests passed, including eight
+remote-control tests (expired/duplicate frames, terminal stop, invalid bounds,
+RC first-gesture zero hold, reversal neutral interval, one-port failure and
+unconfirmed release). Native Tool adapter compiled and passed offline archive
+and output-denial checks on Mini; no hardware access during qualification.
+Control Station: architecture checks, typecheck, 939 unit tests and production
+build passed. The active operator checkout retains its unrelated simulation and
+AI polygon changes. Canonical 8000 was restarted through its existing launchd
+service, preserving configuration and operator data.
+
+Browser acceptance: back returns to the fleet list; full v020 visible; model
+selection persists across reload; Tank changes the key pad to Q/E/A/D; Arcade
+restores W/A/S/D; both layers appear in Available layers; hidden telemetry stays
+hidden after leaving/re-entering, then was restored. Pane maximize/restore keeps
+the scene and canvas sizes correctly. No arm or motion command sent.
+
+Export correction: initial exporter unintentionally included the original
+Blender scenes; visual QA found the studio floor obscuring the rover. Export is
+now limited to the active export scene and selected joined object, verified as
+one scene, one mesh, four donor materials (54,960,576-byte GLB). Immutable v020
+source is unchanged. All donor lighting/postprocess defaults remain unchanged;
+only asset URLs, responsive hosting and model framing adapt to Mission Core.
+
+Node 0.8.41-1 / VESC integration 0.7.0 qualification passed and the versioned
+owner installer completed on Mini. dpkg confirms 0.8.41-1; Node/VESC services
+are active. The paired fast channel supplies fresh RIGHT telemetry with no
+control session. LEFT is absent from Linux USB enumeration, while its UUID
+assignment remains intact; kernel descriptor errors -71 occurred at 11:18–11:19
+MSK, before the installer stopped the driver at 11:20:28. The owner confirms
+USB/power was reconnected during the work. This does not establish the physical
+cause; no USB reset or ad-hoc OS change was performed. The telemetry layer now
+retains missing assigned motors, explicitly shows no connection, and never
+substitutes another UUID or zero measurements.
+Hardware motion, actual channel latency and physical stopping require a fresh
+attended acceptance test. Offline tests do not qualify loaded driving or the
+Mini-independent stop-first RC behavior described above.
+Ship every Node runtime change in the versioned installer; no ad-hoc board edits.
+
+
+### Owner power-cycle and first admission attempt
+
+At 11:35 MSK the owner disconnected/reconnected the battery. Both USB devices
+then enumerated and the existing runtime recovered both assigned UUIDs without
+an application restart or agent-issued port reset. Twenty read-only samples
+(10 seconds) all contained both fresh devices, no active control session.
+
+After fresh owner confirmation (tracks off, raised stationary rig, TX off,
+observing), one Core API trial was armed at 11:38:46 MSK. Initial preflight
+rejected sensorless duty=0.001; no forward command, output claim or temporary
+limit application was reached. This is not a keyboard or motion acceptance.
+
+Source investigation: pinned FW 5.02 mcpwm_foc.c, commit
+3f670137e27e6e383fa79c50cc6b1fa85aab1554, undriven branch lines 2550–2693,
+computes duty_now from measured phase voltages/back EMF even with no driven
+output. commands.c encodes this field with scale 1000. The earlier strict
+zero-duty assumption for observed sensorless standstill was therefore incorrect.
+The new bounded tolerance is one wire quantum, abs(duty)<=0.001, only for that
+already explicitly observed sensorless case. The other current, voltage,
+temperature, fault, input-current and stable-neutral checks remain in force.
+This is an admission bound, not proof of physical stopping or a motor rating.
+New regression verifies both signs of one quantum, rejection of two quanta and
+continued rejection of unobserved speed drift. All 128 VESC tests passed.
+Node 0.8.41-2 / VESC integration 0.7.1 passed qualification and was installed
+through the owner-authorized versioned installer at 12:08:23 MSK; no ad-hoc
+runtime patch and no automatic repeat of movement.
+
+The same follow-up separates terminal input-lease completion from hardware
+faults: normal session end reports stopped only after cleanup; unconfirmed
+release or restoration warnings remain fault. Regression drives the actual
+output loop through the session wrapper and verifies release of both outputs.
+The preceding qualification completed, but its package was superseded before
+installation to include this correction in one owner update. Final VESC suite: 130 tests passed.
+
+Post-install verification: both services active, installed runtime 0.7.1, both
+assigned controller UUIDs fresh after observation refresh (14–205 ms), zero
+currents/duty/fault codes and no control session. Fresh owner observation is
+required for the next attended API trial; physical keyboard/RC acceptance remains pending.
+
+### Attended retry and channel diagnostics
+
+At 12:18:51 MSK, the helper rejected cached device samples before sending arm.
+Read-only refresh restored both fresh UUIDs. The one armed trial at 12:19:28
+remained in preparing for about five seconds, then ended stopped before the
+helper ever sent forward demand. The browser-to-Core zero-demand heartbeat
+continued every approximately 100 ms. No service restart occurred. The current
+evidence does not distinguish a Core transport failure from a Node scheduling
+gap; it does not establish a new USB failure.
+
+Node 0.8.41-3 adds a bounded 32-frame in-memory channel diagnostic recorder,
+flushed to the private service journal on session transitions, transport errors
+or long gaps during a session. It records monotonic intervals, binding wait,
+Core/driver elapsed times, sequence/remaining TTL and state. It excludes trust
+material, endpoints, request bodies and raw HTTP error text. Admission, timeout,
+lease and motor-output behavior are unchanged. Qualification/installation is
+pending; no automatic physical retry.
+
+Node 0.8.41-3 installation completed successfully at 09:36:34 UTC in 18 seconds
+after owner-local Ubuntu authorization. Package version and active Node/VESC
+services verified. Both assigned UUIDs produce fresh readings (190/199 ms),
+zero motor current and fault codes; no control session. Owner observation is
+requested again before one bounded repeat; no motor output sent after the
+12:19 preparation abort.
+
+### Recorded channel timing and operator TCP correction
+
+The attended 12:38:43 MSK retry again ended in preparation without forward
+demand. The new journal localizes the failure to the Core/Node transport budget:
+Core round trips commonly took 100–270 ms, driver calls 1–3 ms and initial
+binding-lock waits zero. One response explicitly expired in transit; another
+response body exceeded the 300 ms HTTP deadline. The first inferred consecutive
+command arrival gap was already greater than its remaining lease. No service
+restart occurred. This does not establish an electrical or USB fault.
+
+Read-only Tailscale checks confirmed DERP(hel) relay rather than a direct path.
+Five Tailscale probes: 42–120 ms; five ICMP probes: 42.8–157.5 ms, zero loss.
+No VPN, route, firewall or onboard OS settings were changed. Private network
+inventory is retained only in the private evidence directory.
+
+The paired Core HTTP handler used the standard TCP Nagle default while writing
+small response headers and JSON separately. Enabled its supported
+disable_nagle_algorithm option (TCP_NODELAY) to remove an avoidable buffering
+source; this does not change authentication, TTLs or output limits. All 52
+Fleet tests passed. Promoted the same narrow change to the active operator
+checkout and restarted its existing launchd service only after verifying no
+active motor session. Canonical 8000 and both fresh controller readings recovered.
+Whether this is sufficient for the current relay path still requires attended
+acceptance; no automatic motion retry.
+
+The 12:46:39 MSK attended retry disproved sufficiency: responses improved to
+47–70 ms at times but still reached 166 ms, and preparation ended before any
+forward command. Four armed remote-channel attempts have now failed in
+preparation; none is a motion acceptance. Subsequent motor trials are paused
+while the command delivery mechanism is corrected.
+
+### Node 0.8.42: independent command stream (qualification pending)
+
+The paired Core endpoint now offers an authenticated NDJSON response containing
+the latest command every 50 ms. Telemetry remains a separate request/response
+channel. Certificate, binding and endpoint revision are checked on every frame.
+No command queue is introduced. Legacy Node clients retain their existing
+exchange response; new clients consume commands only from the stream.
+
+Core attaches a random process clock epoch and an absolute monotonic expiry to
+each command. Node estimates a conservative upper bound on Core clock offset
+using request-send time and the timestamp taken afterward at Core. It never
+assumes symmetric network latency or synchronized wall clocks. A 5 ms margin,
+1000 ppm clock-rate allowance and 25 ms private driver-call reserve reduce the
+remaining lease. The original 400 ms deadline is not extended on receipt or
+repeated frames. Clock calibration expires after two seconds; loss of return
+telemetry retires the Core session after one second. These are software timing
+bounds, not hard-real-time or field-safety certification.
+
+A separate local 20 Hz loop feeds only the latest unexpired intent to the
+single VESC owner. Stream silence cancels its network read after 350 ms;
+disconnect, epoch change, binding change or failed local RPC requires an
+acknowledged null command before accepting further frames. An interrupted
+session remains retired in the existing native-driver lease and cannot resume
+on reconnection. The C++ output watchdog (200 ms), PPM suppression lease
+(250 ms), firmware, calibration and output limits are unchanged.
+
+Qualification covers asymmetric delay, measured relay jitter, original expiry,
+replayed frames, stop-ack races, old clock epochs, stale calibration, silent
+HTTP streams, multiple frames per response and binding revocation midstream.
+Physical API motion, keyboard release/blur and RC takeover acceptance remain
+pending and require fresh owner observation after installation.
+
+Node 0.8.42-1 installed successfully at 10:22:27 UTC. Forty read-only samples
+over ten seconds showed observing/no active session; the last twenty contained
+both assigned controllers with ages at most 217 ms, zero current and fault.
+The freshly authorized 13:25:53 MSK API trial still ended during preparation,
+without forward demand. Unlike the previous transport, the local driver loop
+held 50–51 ms intervals and 1–3 ms responses; no stream disconnect was logged.
+In the retained timeline sequence 26 had about 29 ms remaining at local time
+218304 ms; sequence 28 reached the driver at 218355 ms. This is consistent
+with an expired previous lease despite delivery of a subsequently fresh frame.
+The driver correctly does not revive such a session. It is not evidence of a
+new USB fault or accepted movement.
+
+Follow-up 0.8.42-2 removes periodic-tick waiting for new intent at both ends:
+Core condition notification wakes the stream immediately on accepted input or
+stop; Node uses a one-slot wake signal and always reads the latest intent.
+The 50 ms periodic tick remains a fallback, not an input queue. Tests cover
+updates before/during wait, immediate stop, coalescing and unchanged replay.
+Original 400 ms expiry, output watchdog and current limits remain unchanged.
+The private diagnostic history expands to 128 frames, and terminal telemetry
+no longer triggers idle journal spam solely because it retains a session ID.
+Core tests: 59 passed. This follow-up requires qualification and installation
+before a separately synchronized physical retry.
+
+Owner OS authorization completed: final 0.8.42-2 installed at 10:47:29 UTC
+in 18.67 seconds, all installer steps exit 0; Node and VESC services active.
+Forty read-only samples over ten seconds confirmed observing/no active session.
+The final twenty contained both assigned controllers, at most 216 ms old,
+with zero motor/input current, duty and fault. Fresh owner observation has
+been requested before any new motion; the five previous failed preparation
+attempts remain failures, not movement acceptance.
+
+Sixth attended Core API attempt, 10:52:51 UTC, stopped before forward demand:
+"another VESC operation is running". Recorded command TTL remained 323 ms,
+so this particular failure is different from the preceding lease expiry.
+The remote observer shares operation_lock; _prepare previously attempted
+nonblocking acquisition and treated any overlapping read as a fatal conflict.
+The trace does not identify which operation held the lock; code and a
+concurrent regression reproduce this admission race without hardware.
+
+Candidate Node 0.8.43-1 / VESC 0.7.2 waits up to 500 ms for exclusive access,
+checks the existing input lease every 20 ms and after acquisition, and skips
+new observer cycles while the control worker is alive. It does not queue a
+future drive or extend the input lease. Tests cover completing an in-flight
+read, Stop while waiting, expiry before acquisition, bounded rejection of a
+long operation, and observer yielding. Canonical unittest discovery passes
+135 tests. A first full pytest invocation incorrectly collected the imported
+protocol helper test_packet as a fixture-based test; no product failure was
+reported, and the suite was rerun with its canonical unittest runner.
+Installation and a separately synchronized physical retry are pending.
+
+Node 0.8.43-1 / VESC 0.7.2 installed at 11:06:32 UTC in 18.49 s,
+all installer steps exit 0. Both services active; final 20/40 read-only
+samples contained both assigned UUIDs, age <=219 ms, zero currents/faults,
+observing/no control session. A fresh attended trial is requested separately.
+
+Seventh observed Core API attempt at 11:10:39 UTC reached preparing without
+the ownership fault, then stopped before forward demand. Sequence 19 arrived
+with ~313 ms remaining; sequence 20 followed ~315 ms later, consistent with
+expiry at this boundary. The old trial sent a command, synchronously fetched
+telemetry and only then scheduled its next input. Telemetry reads introduced
+periodic delays up to ~319 ms in its sample cadence. This differs from the UI,
+where the command heartbeat and telemetry poll are independent.
+
+The corrected attended_stream_test.py separates bounded telemetry polling
+from 100 ms command renewal, preserves the same 400 ms lease and all existing
+preflight/stop checks, and records request timing for every command. Synthetic
+checks prove blocked reads do not hold the input path, failures abort and
+reader threads terminate. This is a test-harness correction, not movement
+acceptance or proof that all transport jitter is solved. A fresh observed
+trial is requested; there is no automatic motion retry.
+
+Core-only timing logs were added to distinguish registry wait, archive and
+save delay. All 59 Fleet tests pass; loopback HTTP test needed sandbox network
+permission. The active Core received only this reviewed registry.py diff and
+was restarted without an active session. Read-only samples: max local GET
+179.8 ms, three of forty above 100 ms; retained registry waits 25.9–58.5 ms.
+No archive/save delay above 25 ms was reported in the initial capture. Thus a
+registry persistence bottleneck is not yet established by these measurements.
+
+Eighth observed trial at 11:22:27 UTC still stopped before forward demand.
+Independent input recording showed local Core command POST outliers 103.4,
+166.5, 216.1 and 127.4 ms (normally 2–10 ms). Sequence 17 reached Node with
+312.7 ms remaining; sequence 19 followed after 335 ms. Separating trial
+telemetry therefore did not by itself solve the delivery problem.
+
+A bounded read-only macOS sample of the operator Core found JSON encoding and
+zlib work on its ASGI main thread. The periodically polled completed planning
+report /api/v1/mission-planner/live-tests/active is 2,403,591 bytes and took
+218.5 ms for one local GET. Its endpoint fetched the dict in a worker, but
+FastAPI recursively encoded it and the middleware compressed it on the event
+loop. This shared process also admits rover commands.
+
+planning_live_api.py now constructs the JSON response and optional gzip body
+in the existing thread pool, preserving the full report contract and bypassing
+second compression through Content-Encoding. No polling is disabled, evidence
+is not removed, and Node, calibration, current limits and leases are unchanged.
+13 focused tests passed against development and active Core: JSON/gzip execute
+off-loop, exact content survives decompression, empty/failure contracts and
+existing planning presentation/compression behavior remain valid. Canonical
+8000 was restarted without active control. Sixty ordinary read-only rover
+samples over 15 seconds then had max 86.1 ms, p95 64.5 ms and zero over 100 ms;
+both assigned UUIDs fresh, currents/faults zero. This improves measured delay,
+but does not yet establish motion or field acceptance. A fresh observed retry
+is requested separately. Private process samples and device traces stay out
+of normal Git.
+
+
+Ninth attended Core API trial at 11:31:08 UTC passed preparation and completed
+8 seconds of forward demand at up to 2000 ERPM, with a 30 A ceiling per motor.
+The owner confirmed both motors physically rotated forward and subsequently
+confirmed both stopped. Final state stopped, release_confirmed=true, zero
+motor/input current and fault. Recorded peaks: left 2001 ERPM / 2.88 A motor,
+right 2028 ERPM / 2.81 A motor; these are sampled peaks, not current ceilings.
+During driving device ages stayed <=104 ms, all recorded fault codes zero.
+Preparation retained old motor samples up to 10.1 s while exclusive setup ran;
+those samples are not treated as live motion telemetry. Command POST max
+81.28 ms, p95 10.05 ms across 201 requests. The normal stop command was accepted.
+
+This accepts the observed API forward/release path on Node 0.8.43-1 / VESC
+0.7.2 and the corrected operator Core. It does not accept physical keyboard
+input, Stop/blur, channel loss, RC takeover, loaded or field operation. Those
+remain separate checks. No new calibration, firmware, USB reset or OS change
+was performed for this trial. Private raw evidence and owner notes are hashed
+in the experiment manifest; the previous eight preparation failures remain
+recorded as failures.
+
+
+At 11:38–11:39 UTC the owner physically held W in the 3D View after UI arming,
+then released it. Owner reports both motors forward, immediate perceived stop
+on release and approximately 0.5–1 s before initial motion. Exact key-event
+latency was not instrumented and is not claimed resolved. Read-only capture:
+393 samples, no request errors; driving observed for about 10 s (the requested
+hold was approximately 8 s). Sampled peaks left 2004 ERPM / 3.51 A, right
+2032 ERPM / 2.85 A; driving sample age <=113 ms, all faults zero. Release
+returned to ready with motors stopped; the UI Stop action then reached stopped,
+release_confirmed=true. Final UI explicitly says control disabled. The read-only
+recorder exited and no motion input remained active.
+
+This accepts actual W forward/release, separately from the prior API trial.
+Reverse/turns/Tank, Stop while moving/blur, channel-loss and RC takeover remain
+unaccepted on the new UI path. Owner startup-delay observation is retained
+for a separately instrumented check. No hardware limits or calibration changed.
+MISSIONCOR-85 now records both successful trials, their limits and the previous
+operator event-loop diagnosis while preserving all hardware/Hall history.
+
+
+Observed S/A/D session, 11:45–11:47 UTC: the owner confirmed reverse on S
+and opposite sides on A (left reverse, right forward); also reports D worked
+before the agent disabled control. The telemetry records both opposite-side
+patterns with neutral intervals. Final state stopped, release_confirmed=true.
+The owner reports a repeatable approximately two-second start delay, with
+immediate perceived release. This blocks completion of drive-response acceptance.
+
+Root cause in the remote output loop: it ramps the speed setpoint from zero
+at 600 ERPM/s. Both saved configurations have s_pid_min_erpm=900. Pinned
+upstream bldc mcpwm_foc.c (3f670137e27e6e383fa79c50cc6b1fa85aab1554) forces
+zero duty and resets speed-PID state for targets below that threshold. The
+result is 1.5 s of ineffective commands on each start, plus the retained
+0.5 s undriven interval when changing direction. Recorded telemetry already
+says driving while the rotor remains stopped, consistent with this mechanism.
+This delay is downstream of command admission; the exact key-to-node timing
+was not captured and no claim of zero network delay is made.
+
+Candidate Node 0.8.44-1 / VESC 0.7.3 starts the remote speed request at each
+controller's own read-back minimum PID speed (rounded up for native integer
+setRpm), then ramps at the existing rate above it. It does not change the
+firmware threshold, motor configuration or current ceiling. Subthreshold
+analogue requests release instead of being amplified above the request;
+invalid/unreachable thresholds reject before output claim. Zero input still
+releases immediately; expiry, RC takeover and the reversal dwell remain.
+Synthetic tests cover distinct thresholds including fractional serialization,
+first-cycle output, ramp above the threshold, turn signs, subthreshold input,
+immediate release and invalid thresholds. Physical response after installation
+requires a new observed trial; this candidate is not yet installed.
+
+
+0.8.44-1 qualification completed: all 18 Ubuntu stages succeeded in 268.87 s,
+including 140 VESC tests, Go race checks and Node UI. Source 1b1be6ef5913fd3740a11c69;
+package SHA-256 46cae05efa621a2636251f69ab8071ff4e18db67f23203eab396a71f0ef0972b.
+Owner installer bf270c06ae6d1e598e963756 launched in the local Ubuntu session.
+APT simulation changes only mission-core-node 0.8.43-1 -> 0.8.44-1, with no
+added or removed packages. Before launch Core showed stopped, release confirmed,
+both currents/ERPM/faults zero. Local OS authorization is pending; launch is
+not evidence of installation or an accepted new motor response.
+
+
+Owner authorization completed: 0.8.44-1 installed at 12:01:17 UTC in 18.56 s,
+all installer steps exit 0; Node and VESC services active. Twenty read-only
+samples captured after installation, final sample both assigned controllers
+fresh (53/63 ms), ERPM/current/fault zero and no active control. Fresh owner
+observation requested for W start/release; improved physical response is not
+yet accepted.
+
+
+Post-0.8.44-1 owner keyboard series at 12:05–12:06 UTC included repeated
+forward/reverse and both turn patterns. Owner reports delay approximately
+halved, forward-to-reverse works, but one side sometimes starts sooner.
+Read-only recording: 947 samples, no errors, all faults zero; 23 driving
+segments. First side above 300 ERPM in the same sample or 0.25–0.51 s later;
+both sides by 0–0.76 s. These are state-relative samples, not key-event timing.
+The four-minute recorder ended at ready; a separately saved final snapshot
+confirms stopped/release_confirmed, both ERPM and currents zero after UI Stop.
+Sampled peaks left 2007 ERPM / 5.04 A, right 2025 ERPM / 3.32 A.
+
+Asymmetry diagnosis: after a turn, the remote code held only the reversing
+motor for its 0.5 s neutral interval, while the other side immediately drove
+the new command. Trace 12:05:39 (turn -> forward): right above 300 ERPM in the
+first driving sample, left +0.763 s. The mirror transition at 12:05:33 had
+left first, right +0.511 s. This is a software coordination defect, not evidence
+that all smaller differences arise from the broken left Hall circuit.
+
+Candidate Node 0.8.45-1 / VESC 0.7.4 uses one reversal barrier for the entire
+assigned drive group. If any side reverses, all outputs release until all
+motors have been observed quiet and undriven for 0.5 s, then the current
+latest targets start in the same output cycle. Already observed neutral time
+counts; no extra dwell is added after a sufficiently long released pause.
+Cancelled/replaced direction requests are not queued. The per-controller PID
+threshold correction, speed ramp, immediate zero, current caps, expiry and RC
+priority remain. Synthetic regressions cover turn->straight synchronization,
+a slower coasting companion, counting an existing neutral pause and cancelling
+a pending reversal. Installed software remains 0.8.44-1 pending qualification
+and owner installation of this separate candidate.
+
+
+0.8.45-1 / VESC 0.7.4 passed all 18 Ubuntu qualification stages in 267.11 s,
+including 144 VESC tests. Source d31a8b586b9a600a2a8e61b3; package SHA-256
+ af412c607fec9b34aba0af0e8e67614cd6f4d373fb641d7202341fea30be9ba1.
+Installer f1a8a72c4a1a7efc4aeebedd launched in Ubuntu. Its APT plan upgrades
+only mission-core-node 0.8.44-1 -> 0.8.45-1; no added/removed packages.
+Before launch both controllers had zero ERPM/current/fault, control stopped,
+release confirmed. OS authorization and new physical acceptance are pending.
+
+
+0.8.45-1 installed at 12:23:15 UTC after owner OS authorization, 18.56 s,
+all steps exit 0. Node and VESC services active. Twenty read-only samples;
+final both assigned UUIDs fresh (115/124 ms), zero ERPM/current/fault and
+no control session. Fresh owner observation requested for turn->forward
+transitions; physical synchrony and remaining control/RC acceptance pending.
+
+
+Observed 0.8.45-1 keyboard trial, 12:32–12:34 UTC: 545 read-only samples,
+no read errors, fault codes zero, driving sample age <=105 ms. Twelve driving
+segments; both sides above 300 ERPM in the same sample or within one 0.25 s
+sample. Peaks left/right 2014/2043 ERPM and 4.35/3.24 A. Owner reports responsive
+forward/reverse/turns. This is coarse telemetry, not exact key-to-output timing.
+
+CRITICAL physical acceptance failure: owner reports D continued after leaving
+the browser and releasing the physical key; later clicks recovered it. The
+trace contains prolonged D segments (22.82 and 20.56 s), but browser focus/key
+source events were not recorded, so exact focus-loss latency is unknown.
+Agent ended control through UI; stopped/release_confirmed=true and both motors
+zero ERPM/current/fault. Remote-control acceptance remains blocked by this defect.
+
+The UI already subscribed to blur/pagehide/visibility events. Its 100 ms
+command sender nevertheless renewed a remembered nonzero demand without a
+focus or input-freshness check; a missed browser-host event could hold it
+indefinitely. Fix uses a core-owned held-input binding, capture listeners,
+50 ms focus polling, and a guard checked at every command heartbeat. A key
+requires a fresh trusted press, then OS-repeat evidence: <=1000 ms initially,
+<=300 ms after a repeat. This fallback bounds a lost keyup even if the host
+also misses focus events. Focus loss/expiry clears all held states and disarms;
+returning focus or delivering a late repeat cannot resume movement. Continuous
+keyboard control therefore requires OS repeat within those bounds; this is
+not a global-background keyboard implementation. Pointer up/cancel/capture-loss
+and component disposal release held state. No onboard install or firmware/config
+change belongs to this UI fix. Physical focus-loss re-test remains pending.
+
+
+Owner follow-up after the first focus fix: movement now stops on focus loss,
+but terminating the control session is explicitly rejected. New required
+behavior is neutral hold with the current healthy control session preserved;
+returning focus requires a new physical press, not another arm/preparation.
+The implementation now separates input pause (clear held input, send zero,
+keep session) from explicit Stop/pagehide/unmount/fault (end session). Guards
+still run before every send; old demand is never restored on focus return.
+The periodic neutral messages maintain the session only while communication
+remains healthy. Actual background suspension/channel expiry is still a stop,
+not permission to extend the motion watchdog. Continuous keyboard holds still
+require OS repeat evidence within the bounded input lease.
+
+Preparation now hides key controls and renders the existing canonical warning
+StatusBadge as Подготовка управления; readiness alone admits the green state
+and key controls. Initial focus-fix physical evidence confirms stopping but
+not the requested session-preserving behavior. Revised physical test pending.
+
+
+Final revised UI qualification: 934 unit tests, architecture checks, TypeScript
+and production build pass. Canonical Core serves the exact new index/assets;
+no Node/OS/firmware change. Browser verified amber Подготовка управления with
+keys absent until ready. Owner observed the revised trial and confirmed:
+focus loss stops motors, returning allows a fresh press without another arm
+or preparation. One active session persisted throughout all six short driving
+segments. Explicit UI Stop after completion ended the session; final fresh
+telemetry confirms stopped/release_confirmed=true, both ERPM/current/fault zero.
+The private result includes UTC/monotonic traces, owner notes and SHA-256.
+This accepts focus loss/resume on the observed host. Tank, explicit Stop while
+moving, command-channel loss, RC takeover and loaded/field behavior remain
+separate outstanding physical checks. No exact key-to-stop timing is claimed.
+
+
+Startup-entry follow-up, 2026-09-25: owner reports silently disabled Manage
+and intermittent first-arm failure on a fresh Core page. The outer button
+previously depended on fresh/supported status without explaining the wait.
+A reproduced hook race allowed a poll begun during POST /arm to return the
+old controlling=false state after the arm acknowledgement and revoke the new
+session. The error path had the same missing generation guard; repeated arm
+calls before acknowledgement also escaped the session-only check. Three new
+regressions failed before the fix; actual current-generation authority loss
+already passed and must continue to end control.
+
+The acknowledgement now retires pre-acknowledgement reads; poll success and
+failure require the current generation. An in-flight arm guard prevents
+duplicate submission. Status reads may wait 1000 ms; command/arm 350 ms
+deadlines and all board motion watchdogs remain unchanged. Manage always
+opens settings, while actual arm waits for fresh supported idle authority.
+The dialog remains open on failed arm. Canonical amber status distinguishes
+synchronization, preparation, unavailable data and previous-session cleanup;
+ready alone shows green and motion keys. Title is now exactly
+«Центр наблюдения и управления». No board install/configuration change.
+
+Validation: 938 unit tests, architecture check, TypeScript and production
+build passed; final copy/color adjustment rechecked with 22 focused tests
+and production build. Fresh browser entry acquired control on its first click.
+13:20:28–13:20:38 UTC preparation was visible, then ready; no motion input
+was sent. Explicit UI Stop completed at 13:21:09 UTC, release confirmed.
+307 read-only samples, no read errors, all ERPM and fault codes zero.
+A subsequent page reload and settings reopen also passed. These are bounded
+UI/lifecycle checks, not new acceptance of driving or RC takeover. Private
+entry-startup-result.json contains UTC/monotonic evidence and SHA-256 hashes.