# Submission Check > Gate the three ERC-26 Phase 1 deliverables against every stated requirement before the 2026-09-15 submission. Checks the launch contract, package dependencies, clean-container build, the video's six constraints, and the report's six mandated sections. Use in the final week, and before submitting. - Skill: `faaz17/submission-check` (Agent Skill) - Install (CLI): `npx skillmds@latest add faaz17/submission-check` - Raw SKILL.md: https://api.skillmd.com/api/skills/faaz17/submission-check/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: Faaz17 (https://skillmd.com/u/faaz17) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/faaz17/submission-check --- # /submission-check, deliverables gate The last thing that runs before submitting. Its job is to catch the defects that make good work score zero. Two failure modes it exists for, both stated by the organisers as absolute: 1. A submission that depends on environment modifications, or does not run correctly inside the provided Docker image, **will not be evaluated**. 2. A submission whose launch file does not accept `shelf_column_number` and `book_colour` correctly **will not be evaluated**. Neither is a deduction. Both discard everything. ## Steps Work through all four blocks. Report every unchecked item, and do not summarise a partial pass as a pass. ### Block 1: evaluation risk, check these first Anything failing here means the submission is not graded at all. - [ ] `solution.launch.py` accepts both arguments, tested with the **literal** organiser command: `ros2 launch solution.launch.py shelf_column_number:=2 book_colour:=red` - [ ] **Every** dependency declared in `package.xml`, verified by a fresh-clone build in a fresh container, not by reading the file - [ ] No modification to the provided Docker environment: OS, ROS 2 distribution, Gazebo version, robot model - [ ] Fresh clone into a fresh container: `colcon build` clean with **zero** manual fixes - [ ] Runs on a second machine, if one exists - [ ] Repository is public and the link resolves without a login - [ ] Scored topic names and types exactly as specified, never renamed: `/erc/shelf_column_identification` and `/erc/shelf_row_identification`, both `std_msgs/msg/Int32` ### Block 2: code, 20% - [ ] Perception, planning and execution in **distinct nodes**, not one file - [ ] `README.md` in the repository describing the packages the team created - [ ] Comments explaining functions and sections - [ ] Every stage has a timeout and a retry budget - [ ] Recovery paths exist for missed grasps, lost topics and unexpected sensor input, and each has been deliberately triggered at least once - [ ] No dead code, no commented-out blocks - [ ] All tunables in `config/params.yaml`, none embedded in nodes - [ ] No hard-coded shelf pose, row height, or digit-to-column mapping - [ ] `main` builds clean and is the commit being submitted ### Block 3: video, 10% Every item is individually disqualifying. - [ ] Duration **5:00 or under** - [ ] Single continuous recording, **no cuts** - [ ] **Not sped up**, including subtle speed changes - [ ] On-screen timer visible from trial start to finish - [ ] Team name visible **before** the trial begins - [ ] Opens by launching `simulation.launch.py`, **then** `solution.launch.py` - [ ] Launch command shows both arguments - [ ] Every scored task visible in frame - [ ] Uploaded to YouTube, link accessible without login - [ ] **The recorded code matches the submitted commit** - [ ] Consistent with what the report claims ### Block 4: report, 20% - [ ] PDF format - [ ] **Rendered page count is 5 or fewer**, excluding the title page. Check the render, not the source - [ ] Section 1, system architecture, **with a node diagram** - [ ] Section 2, perception, **with quantitative accuracy across trials** - [ ] Section 3, navigation, **with travel time data and RViz planned-versus-executed screenshots** - [ ] Section 4, manipulation - [ ] Section 5, results, **with scores across 5 trials, detection and grasp success rates, average time** - [ ] Section 6, limitations and future work - [ ] Six sections in the mandated order, used as literal headings - [ ] Every number traceable to `results/trials.csv` - [ ] No claim that a test produced a result it did not - [ ] Humanizer pass applied, with all measurements, tables and citations preserved - [ ] `Clean Technical Document` standard applied, and every rendered page inspected for blank pages, clipping, overlap and table borders ### Block 5: the artifacts on disk - [ ] `erc_images/` contains images from real trial runs, each timestamped, each with a visible bounding box - [ ] No stale images from outside a trial run - [ ] `results/trials.csv` has at least the five report trials, logged with no parameter changes between them - [ ] The submission form itself has been located and filled. The organisers provide it closer to the deadline ## Output format ``` ## Submission check, , days to 2026-09-15 ### Evaluation risk ### Code (20%) / checks pass. Failing: ### Video (10%) / checks pass. Failing: ### Report (20%) / checks pass. Failing: ### Artifacts / checks pass. Failing: ## Verdict ``` ## Rules - **Report evaluation risk separately and first.** A perfect solution that is not evaluated scores zero, so that class of defect outranks every other finding regardless of how small the fix is. - **Verify, don't read.** The dependency check means building from a fresh clone in a fresh container. Reading `package.xml` proves nothing about what was installed by hand months ago. - **Check the rendered page count.** The 5-page limit applies to the PDF, and a source document that looks short can render to six pages. - **Check the video's duration and speed with a tool,** not by eye. Both are trivially checkable by the committee and both are disqualifying. - **Never report a partial pass as a pass.** List every unchecked item. - If the submission form has not been located yet, flag it. It is an external dependency and the organisers release it late.