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 <package> 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, <date>, <days> days to 2026-09-15

### Evaluation risk
<PASS, or the failing items. Anything here blocks everything>

### Code (20%)
<n>/<n> checks pass. Failing: <list>

### Video (10%)
<n>/<n> checks pass. Failing: <list>

### Report (20%)
<n>/<n> checks pass. Failing: <list>

### Artifacts
<n>/<n> checks pass. Failing: <list>

## Verdict
<READY TO SUBMIT, or the ordered list of what must be fixed first>

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.