Pre-Submission Review for Robotics Papers

Robotics reviewers often ask:

• what robot, sensors, actuators, controller, and environment were used?
• is the task defined tightly enough to evaluate success?
• are baselines tuned fairly and matched to the robot setup?
• do experiments test real hardware, simulation, or both?
• are ablations, failure cases, and safety limits shown?
• do videos or multimedia evidence support the claims?
• can another lab reproduce the setup, policy, controller, or evaluation?
• does the paper fit IEEE Transactions on Robotics, IJRR, Science Robotics, ACM THRI, ICRA or IROS extensions, or an AI venue?

The manuscript has to prove the method works as robotics, not only as code.

In our pre-submission review work, robotics manuscripts most often fail when the real-world system evidence is too thin for the strength of the claim.

Task-definition gap: success is reported, but the task, constraints, objects, environment, and failure conditions are not precise enough.

Hardware opacity: sensor calibration, robot limits, controller settings, payload, latency, friction, or safety constraints are underreported.

Simulation overreach: simulation results are written as if they demonstrate hardware robustness.

Baseline weakness: the new method beats a weak, undertuned, or poorly adapted comparison.

Video-evidence gap: the paper describes behavior that reviewers need to see, but multimedia evidence is missing or too polished to reveal failures.

A useful review should identify the first robot-specific objection that would make reviewers doubt the result.

IEEE Transactions on Robotics warns that failure to follow author guidelines can result in return without review. IJRR asks authors to address data availability and supports multimedia extensions, which matters in robotics because behavior, failure modes, and task execution are often easier to judge in video than in prose. ACM Transactions on Human-Robot Interaction explicitly spans robotics, computer science, engineering, design, and behavioral and social sciences, so HRI submissions need both system and human-evidence discipline.

These signals point to the same readiness standard: robotics manuscripts need experimental traceability, not only formal method description.

Send the manuscript, target journal, robot platform specs, hardware setup photos, controller details, sensor calibration notes, task definition, simulation details, real-world experiment logs, baseline implementations, ablation plan, failure videos, safety notes, code and data availability plan, figures, supplement, and prior reviewer comments.

For HRI robotics papers, include participant protocol, consent, risk mitigation, task environment, interaction script, and analysis plan. For field robotics, include site conditions, weather, terrain, sensor failures, and recovery procedures.

A useful robotics pre-submission review should include:

• robotics contribution verdict
• task and system-definition critique
• hardware, controller, and sensor reporting review
• baseline, ablation, and experiment-design check
• safety, failure, and multimedia-evidence review
• reproducibility and data/code readiness note
• journal-lane recommendation
• submit, revise, retarget, or diagnose deeper call

The review should not only say "run more experiments." It should name the experiment that would change reviewer confidence.

Before submission, authors often need to:

• define the robot task and success criteria more tightly
• add hardware, controller, and sensor details
• separate simulation evidence from real-world evidence
• add failure analysis and ablations
• strengthen or retune baselines
• add videos that show representative successes and failures
• clarify safety limits and human-risk controls
• retarget from robotics to ML, HCI, automation, medical devices, or domain venues when the embodied contribution is secondary

These fixes make the robotics claim easier to trust.

A manipulation paper needs object diversity, grasp or contact failure analysis, and repeatability. A navigation paper needs environment variation, localization failure handling, and path-planning comparison. A control paper needs stability, robustness, and hardware limits. A robot-learning paper needs simulation-to-real boundaries, baseline discipline, and ablation. An HRI robotics paper needs participant evidence and ethical safeguards. A field robotics paper needs site conditions and failure recovery. A surgical robotics methods paper needs safety and clinical-task framing without pretending it is already a clinical outcome study.

The AI manuscript review can flag whether the blocking risk is hardware detail, experiments, baselines, video evidence, or journal fit.

Use this page when the manuscript's submission risk depends on robot hardware, embodied validation, control, sensing, actuation, task execution, failure behavior, field deployment, or robotics venue fit. Use AI or machine learning review when the main contribution is a general algorithm. Use HCI review when the main claim is about user experience, interaction design, or human study evidence rather than the robot system.

That distinction keeps the page focused on the robotics buyer's actual problem.

Do not submit a robotics paper if the task definition is loose. Reviewers need to know exactly what the robot had to do, under what constraints, and what counted as failure.

Also pause if the strongest result exists only in simulation. Simulation can be useful, but the manuscript should not imply embodied robustness unless the evidence supports that claim.

For robot-learning papers, pause if baselines are weak. A new policy that beats an undertuned controller or a poorly adapted prior model may not survive review.

For HRI or safety-relevant work, pause if participant risk, robot failure, or operator intervention is hidden. Robotics reviewers are often more forgiving of honest failures than of sanitized demonstrations.