← BlogDebugging War Stories· 2/5

The Joint Was Running 40× Over the Speed Limit — What Peak KPI Hid: 12,078 dps

A peak KPI that only measured maximum lift height kept awarding PASS even when the arm dropped the object mid-transfer. Once trajectory KPIs were added, cells that had been marked PASS turned out to have joint velocities 40× over the recommended limit.

~4 min
debuggingmanipulatorKPItrajectorywar-story

The Joint Was Running 40× Over the Speed Limit

We were validating a robotic arm simulation — pick, transfer, place. The KPI said "PASS." But watching the video, the arm was thrashing wildly, grabbing and dropping the object repeatedly. Numbers said pass; eyes said clear failure. Where was the disconnect?

The Blind Spot of Peak KPI

The cause was in the metric itself. At the time, "did the arm lift the object" was measured as maximum height (peak) — lift = peak height − start height. The problem: even if the arm drops the object mid-transfer, that peak value is still on the record.

Rendering diagram…

Peak says "if it was lifted even once, it passes." Drop the object 19 times mid-transfer, recover once, and that single peak height earns a PASS.

What Trajectory KPI Revealed

So we added trajectory KPIs — logging object position, grip duration, joint velocity, and wrist rotation at every timestep (10 Hz). The truth came out.

The worst-performing cell (multi-cube waypoint transfer) showed:

  • Peak joint velocity: 12,078 deg/s — 40× the ISO recommended limit (~300)
  • Accumulated wrist rotation: 697°
  • Object drops during transfer: 19

Per-cell peak joint velocity (log scale). Peak KPI passed everything, but PICKPLACE was actually running at 12,078 dps — 40× the limit (300, green line). Cells that genuinely passed (cyan) sit near the limit.Per-cell peak joint velocity (log scale). Peak KPI passed everything, but PICKPLACE was actually running at 12,078 dps — 40× the limit (300, green line). Cells that genuinely passed (cyan) sit near the limit.

The chart makes it obvious — some of the cells that were logged as "PASS" tower above the limit, even on a log scale.

⚠️ Peak hides behavior — A metric that only looks at the maximum value can't see how that maximum was reached. Lifting an object smoothly and lifting it after dropping it 19 times are completely different behaviors, even if the final height is identical. You need trajectory to see the difference.

What a Genuine PASS Looks Like

The three cells that genuinely passed shared a clear profile.

  • Single-cube, short motion — fewer waypoints, joint velocity near the limit (~299 dps).
  • Reinforcement learning policy — a learned, smooth motion with the longest grip duration (8.57 seconds).

The failing cells all involved multi-cube waypoint transfers where the motion planner aggressively changed configurations, causing joint runaway.

💡 Don't trust "number PASS" — watch the behavior — The lesson here is that even when a KPI passes, you need to verify how it passed by looking at the trajectory. The user's intuition that "the video looks wrong" was correct; the peak numbers had been masking it.

In a nutshell

📌 A peak KPI measuring only "maximum lift height" awarded PASS even after 19 mid-transfer drops. Adding trajectory KPIs (per-timestep position, grip time, joint velocity) revealed that the supposedly-passing cells had joint velocities at 40× the limit (12,078 dps). Watch the behavior, not just the number.

See standard test results with videos and verdict evidence on the imSim Portal.

View public results →