Iros artifact evaluation
Skill brycewang-stanford/Awesome-Journal-Skills/IROS-Skills/skills/iros-artifact-evaluation
Journal-specific Claude Code/Codex skill packs covering mainstream journals — AER, QJE, Nature, Cell, 管理世界, 经济研究 & 200+ more — your fast track to getting published. | 覆盖主流期刊的 Claude Code/Codex 期刊技能包,从选题、识别策略到表格规范与审稿回复全流程,助你快速发论文。
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill iros-artifact-evaluationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
What its author says it does
Copied from the file, not written here
Use when packaging IROS evidence for a skeptical reviewer even though IROS runs no formal artifact track — the robotics artifact stack of hardware ledger, logs, configs, code, and data, what an embodied-systems reviewer opens first, review-time anonymity versus acceptance-time public release, and making a claim auditable not asserted.
SKILL.md
3.8 KB, 774 tokens by cl100k_base, as published. Nobody here has run it
IROS Artifact Evaluation
IROS has no formal artifact-evaluation track or badge, so "artifact" here means the evidence bundle a reviewer could inspect and that a careful author prepares anyway. The audience is an embodied-systems reviewer who trusts a logged trajectory over a claimed one, and who cannot rerun your robot but can read your logs, configs, and code.
The robotics artifact stack
- Hardware ledger: platform, sensors (make/model/firmware), actuators, onboard computer, and power budget — the embodiment the result depends on.
- Logs: time-stamped rosbag-equivalent recordings for representative trials, so a claim about a contact force or trajectory is auditable.
- Configs: the exact parameters, calibration, and launch files that produced the reported runs.
- Code: the system as run, with an entry point and a one-minute orientation in the README.
- Data: any dataset or object set, with provenance and licensing; for restricted data, enough detail for credible reproduction without violating terms.
What an IROS reviewer inspects first
| Claim type | First artifact inspected | Common failure caught |
|---|---|---|
| "Runs onboard at rate X" | Timing logs and the compute/power spec | Rate measured on a desktop, not the robot |
| "Reliable across trials" | The trial log and failure record | Success rate with resets and failures omitted |
| "Transfers from sim" | Paired sim and real logs | Only sim logs exist; the gap is asserted |
| "Beats prior system" | Baseline configs on the same platform | Baseline run with different hardware or tuning |
Because a reviewer will read a log far sooner than rebuild a robot, make the logs and configs legible first, and polish the code second.
Review-time versus acceptance-time states
- Review time (double-anonymous): strip organization names, cluster paths, calibration files tagged with a lab, commit authorship, and any URL carrying a lab identity. If you link code, use an anonymized mirror or omit the link and describe the artifact.
- Acceptance time: replace anonymized stand-ins with a public, licensed, citable release; test every link from a logged-out browser; and add the DOI or archival link the IEEE Xplore record can point to.
Worked vignette: packaging a field-robot result
A submission claims a lidar-inertial system runs onboard across three outdoor sites.
- Ship one representative rosbag per site plus the launch/config that processed it, so a reviewer can see the sensor streams and the estimated trajectory line up.
- Record the compute-and-power measurement method, not just a headline rate.
- Emit the trajectory-error tables directly from the logged runs so the paper numbers and the artifact cannot drift apart.
- State which site is easy and which stresses the system, since that mapping is what a reviewer grades.
Artifact layout:
/hardware.md platform, sensors, compute, power
/logs/<site>/ time-stamped bags for representative trials
/config/ calibration, params, launch files
/src/ system as run + README (1-minute orientation)
/data/ provenance + license (or access instructions)
Output format
[Artifact role] review-time anonymous / acceptance-time public
[Contents] <hardware/logs/configs/code/data>
[Anonymity risks] <paths/metadata/URLs/calibration tags>
[Auditability] logged / scripted / described / asserted
[Fixes before upload] <ordered list>