75 lines
5.6 KiB
Markdown
75 lines
5.6 KiB
Markdown
# Актуальные заметки по соревнованию
|
||
|
||
## Рабочие допущения
|
||
|
||
- Будет отдельный день настройки оборудования.
|
||
- Основной ожидаемый формат — физические РМК, но 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 или аргументах запуска.
|
||
|
||
### Модуль А — диагностика
|
||
|
||
- заменить диагностируемую плату;
|
||
- изменить набор заранее внесённых неисправностей;
|
||
- использовать единый шаблон отчёта;
|
||
- ограничить дефекты теми, которые обнаруживаются осмотром и мультиметром без пайки.
|
||
|
||
Этот вариант безопасен только при наличии схемы или документации на плату и заранее определённого перечня допустимых неисправностей.
|