Update joint limits docs for velocity and acceleration

[Shannon Bradshaw (shannonbradshaw)]

RDK#6361 added max_velocity and max_acceleration fields to the Limit struct and JointConfig, allowing kinematics files and input_range_override to specify per-joint speed and acceleration bounds.

Source changes

• RSDK-14418: add per-joint velocity and acceleration limits to SVA rdk#6361: Add per-joint velocity and acceleration limits to SVA

Docs changes

• docs/motion-planning/reference/kinematics.md: Expanded the "Joint limits" section to document optional max_velocity and max_acceleration fields. Added the two new fields to the SVA JSON field reference list. Updated the mimic joint constraint to note that mimic joints must not declare velocity or acceleration limits.
• docs/motion-planning/reference/motion-service.md: Updated the input_range_override attribute description to document the new max_velocity and max_acceleration override fields and the tighten-only behavior (overrides can slow a joint down but never speed it up past what the kinematics file declares).

How I found these

• Xref lookup: config-xref.md and flows.md motion planning references
• Grep matches: searched for input_range_override, joint.*limit, max_velocity, max_acceleration, JointConfig, and kinematics.*file across the entire docs repo

---

Generated by daily docs change agent

---

Generated by Claude Code

[netlify]

✅ Deploy Preview for viam-docs ready!

Name	Link
🔨 Latest commit	fed0b5f
🔍 Latest deploy log	https://app.netlify.com/projects/viam-docs/deploys/6a8730761ae7b60008d33e5a
😎 Deploy Preview	https://deploy-preview-5274--viam-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 43 (🟢 up 5 from production) Accessibility: 100 (no change from production) Best Practices: 100 (🟢 up 8 from production) SEO: 92 (no change from production) PWA: 60 (no change from production) View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Jeremy Rose (jeremyrose-viam)]

Adversarial review

Ran an adversarial check on this PR, cross-referenced against the RDK source PR it documents (viamrobotics/rdk#6361, merged 2026-08-19). Found 4 issues:

1. Docs state the limits are enforced today, but nothing consumes them yet (docs/motion-planning/reference/kinematics.md:75)

The doc says these limits let "the trajectory generator produce timed paths." RDK#6361 explicitly says: "Nothing in the tree consumes the limits yet... arm modules that publish them... are separate changes." The follow-up (rdk#6370) is still open/unmerged. A reader configuring max_velocity/max_acceleration today would reasonably expect viam-server to slow the arm down — it won't, and there's no indication in the docs that the feature is currently inert.

This also happens to be the exact thing RSDK-14427 (the docs ticket for this scope) calls out by name: "Worth stating explicitly that nothing enforces these limits today, so a reader does not expect the motion service to reject a fast move." Recommend adding that caveat explicitly.

2. Position-limit override is missing the safety caveat the velocity/acceleration override gets (docs/motion-planning/reference/motion-service.md:59)

The velocity/acceleration sentence for input_range_override explicitly promises tighten-only behavior (can't be raised past the kinematics file's declared limit). The position-limit sentence right next to it says limits are replaced "outright," with no equivalent caveat. Per RDK, NewModelWithLimitOverrides assigns position min/max outright with no clamping — so a user relying on the tighten-only mental model from the adjacent sentence could unknowingly command the arm past the kinematics file's declared physical safety range.

3. 0 vs. omitted field isn't documented as a meaningful distinction (docs/motion-planning/reference/kinematics.md:67)

Docs say omitting max_velocity/max_acceleration means unbounded, but don't mention that an explicit 0 is different — RDK#6361 treats 0 as "the joint cannot move at all." A user writing "max_velocity": 0 intending "no limit" (a reasonable guess if they assume 0 is a no-op like an omitted field) would get a frozen joint with no documented explanation.

4. Minor: intro sentence scope no longer matches the bullet list (docs/motion-planning/reference/kinematics.md:59)

"Every joint has limits that define its range of motion" wasn't updated even though the list now includes Max velocity/Max acceleration, which aren't range-of-motion limits. Low-severity, but worth a tweak so the new bullets don't read as another position-limit variant.

---

Posted by Claude — adversarial pass cross-referenced against rdk#6361 and RSDK-14427/RSDK-14384.

[Shannon Bradshaw (shannonbradshaw)]

Thanks — accepted all four. Fixed in fed0b5f.

1. Limits not enforced yet. Confirmed against the source: TrajectoryLimits in referenceframe/frame.go is referenced only from referenceframe/joint_limits_test.go, so nothing in the planner consumes it. Added a caution alert to both pages stating the fields are stored in the kinematic model and returned by GetKinematics, but no built-in planner or arm module enforces them during planning or execution, and readers should not rely on them to limit joint speed until a future release adds enforcement.

2. Position-override safety caveat. You're right that the asymmetry was misleading. Restructured input_range_override so the table cell stays short and the semantics move into a new "How input_range_override applies limits" section, which states plainly that position limits replace the kinematics file's values outright with no clamping, that an override can therefore widen a joint's range past what the file declares, and that values should be verified against the manufacturer's documented limits first.

3. 0 versus omitted. Added to both bullets: omit the field to leave the joint unbounded; an explicit 0 means the joint cannot move at all.

4. Intro sentence scope. Reworded to "Every joint declares position bounds and, optionally, speed bounds" so the velocity and acceleration bullets don't read as position-limit variants.

prettier, markdownlint, and vale all pass; the new cross-page anchor (/motion-planning/reference/kinematics/#joint-limits) resolves.

---

Generated by Claude Code