# Актуальные заметки по соревнованию

## Рабочие допущения

- Будет отдельный день настройки оборудования.
- Основной ожидаемый формат — физические РМК, но Webots остаётся запасным и учебным вариантом.
- На физических РМК ожидается тот же ROS 2 API. Если площадка выдаёт другое окружение без документации и времени адаптации, это нужно сразу поднимать как проблему инфраструктуры.
- Интернет и документация разрешены.
- По телефонному разъяснению эксперта LLM разрешены, формат близок к хакатону. Это устное актуальное разъяснение; его стоит повторно зафиксировать на инструктаже.
- Целевой ArUco ID сообщает эксперт.
- Для модуля В, вероятно, понадобится новый датасет с выданной камеры и физических деталей либо готовый датасет организаторов.
- Для модуля Г важнее работоспособный интерфейс по критериям, чем сложный дизайн.

## Ограничение числа скриптов

По полному финальному КЗ:

| Модуль | Максимум взаимодействий/скриптов на зачётном ПК |
| --- | ---: |
| Б | 2 |
| В | 1 |
| Д | 4 |

Текущий `module5/module5.py`, запускаемый одним процессом, не нарушает ограничение модуля Д. Он не использует собственный UDP-протокол: один ROS 2 node на зачётном ПК публикует команды в пространства `/RMC1/*` и `/RMC2/*` и получает телеметрию обоих роботов через DDS.

Это работает, если оба физических РМК доступны в одном согласованном ROS-домене. Если площадка разведёт роботов по разным доменам или компьютерам, архитектуру нужно будет адаптировать в день настройки.

Официальный сценарий модуля Д допускает последовательные или параллельные операции. Текущее решение выполняет их последовательно — медленнее, но проще и безопаснее.

## Предлагаемые изменения 30%

### Модуль Б — навигация

- заменить ID стартового и целевого ArUco;
- переставить несколько закрытых ячеек;
- изменить место появления динамического препятствия;
- передавать старт, финиш и препятствия через конфиг.

Это меняет входные данные, но сохраняет планировщик, маршрут, возврат, объезд и оценку времени.

### Модуль В — техническое зрение

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

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

### Модуль Г — GUI/FMS

- переключатель РМК-1/РМК-2;
- состояния `ONLINE/OFFLINE`, `AUTO/MANUAL/STOP`;
- перестановка блоков интерфейса;
- цвет свободных и занятых ячеек;
- окно последних событий;
- неизменные ROS-топики и сервисы.

### Модуль Д — складской сценарий

- менять ячейки хранения, комплектации и выдачи;
- выбирать другую известную деталь;
- менять порядок существующих операций;
- сохранять РМК, ARM95 и ROS-интерфейсы;
- хранить точки и класс детали в YAML/JSON или аргументах запуска.

### Модуль А — диагностика

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

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