Quartz 5

What do Software Engineers misunderstand about Robotics?

Properties1
tagsblog, robotics

4 min read

Summary

The author lists six misunderstandings software engineers bring to robotics — that software tools transfer directly, that simulation is a trustworthy test suite, that unit-test-style pass/fail applies, that foundation models remove the need for verification, that iteration speed is a discipline problem, and that robotics is a niche — arguing each stems from the same root cause: robotics code runs against physics, not a deterministic runtime, so the missing infrastructure is reproducible environment + physically-grounded simulation + probabilistic evaluation tooling, none of which mainstream software engineering culture has built yet.

作者列出軟體工程師對機器人學的六個常見誤解——軟體工具可以直接沿用、模擬可以當作可信的測試套件、單元測試式的 pass/fail 可以套用、基礎模型讓驗證變得不必要、迭代速度只是紀律問題、機器人學是個小眾領域——並指出這些誤解的根源相同：機器人程式碼是對物理世界而非確定性 runtime 執行的，因此真正缺少的基礎設施是「可重現的環境 + 基於真實物理的模擬 + 機率式的評估工具」，而這些正是主流軟體工程文化目前尚未建立的。

Key Points

  • Misunderstanding 1: Git/CI/tests/containers don’t transfer because the same code+input can produce different outputs depending on friction, temperature, exact object placement — a commit captures code perfectly but nothing about the physical environment it ran in
  • Misunderstanding 2: simulation is treated as a test suite but engineers don’t actually trust it, so they fall back to real hardware anyway — the fix isn’t “a better simulator,” it’s simulation built from real measured friction/sensor-noise/motor-response instead of approximations
  • Misunderstanding 3: standard test-pass/fail assumes binary outcomes, but robotics gives probabilistic results (e.g. “94% grasp rate”) — there’s no standard answer to whether a change made the robot better, and evaluation tooling is described as “the real missing discipline”
  • Misunderstanding 4: better foundation-model policies raise the value of verification rather than removing the need for it — the best live demos come from teams with the deepest internal testing/eval loops, not the smartest models alone
  • Misunderstanding 5: when one experiment takes 20 minutes and needs physical hardware, “iterate fast” stops being a discipline problem and becomes a hardware-availability problem — whoever shortens that loop changes the field’s output, not just their own team’s speed
  • Misunderstanding 6: every physical-AI company today is effectively a software company with a hardware problem, independently rebuilding the same missing infrastructure in parallel — draws the analogy to chip design (didn’t scale until verification tooling arrived) and autonomous vehicles (didn’t scale until simulation was industrialized)

Insights

  • This is a direct, first-person articulation of exactly the “software engineer onboarding gap” pattern this vault already tracks in raw/research/ (teleoperation, sim-to-real, evaluation tooling notes) — worth cross-linking as a concise, quotable framing of why robotics infra is hard, distinct from the algorithms
  • The framing “testing usually assumes a binary outcome when robotics rarely gives you one” is a crisp one-liner for why CI/CD culture (as covered in the CI/CD roadmap clipped in the same batch) doesn’t directly transfer to robot learning pipelines — worth connecting the two when reasoning about MLOps-for-robotics tooling gaps
  • The “everyone is rebuilding the same missing layer in parallel” claim matches this vault’s own primary research interest in robotics infrastructure/tooling — a candidate seed for a future /research-vault pass on what shared infra actually exists (e.g. LeRobot, ROS2 tooling already in raw/research/)

Connections

Raw Excerpt

Your code is not running against physics not a runtime. Same input can have different outputs depending on friction, temperature, exactly where an object happened to land.

Graph View

Backlinks