跳到主要内容
知仓学习社ZHICANG

iros-artifact-evaluation

Use when packaging IROS evidence for a skeptical reviewer even though IROS runs no formal artifact track — the robotics artifact stack of hardware l…

不碰外部(只输出文字)无严重或高危命中brycewang-stanford/Awesome-Journal-Skills

它会碰到什么

扫了多少1 个文本文件,4 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0

这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。

技能内容

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>

想直接用这个技能?

本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。