[RSDK-14385] Emit per-joint velocity and acceleration limits

[JohnN193]

Ticket 7 of RSDK-14385. The SVA kinematics schema now carries optional per-joint max_velocity and max_acceleration so the motion service can generate trajectories itself instead of handing arms a path and asking them to build a kinematic chain. This publishes them from our synthesized document.

What changed

• JointLimits gains max_velocity_deg_per_sec and max_acceleration_deg_per_sec2 as std::optional, because an absent field is how the schema spells unbounded and the shipped kinematics/<model>.json files carry position bounds only.
• Kinematics::with_kinematic_limits attaches per-joint limits, taking radians (what state_ holds) and converting to the degrees the schema uses.
• to_sva_json writes each field only when set. load_kinematics reads them back, so a document we emit reparses to what we wrote.
• state_::create captures the configured limits once, and get_dh_kinematics_json stamps them inside the existing call_once.

What we publish, and one deliberate tradeoff

The values are the configured speed_degs_per_sec and acceleration_degs_per_sec2, already clamped against any max_speed_degs_per_sec / max_acceleration_degs_per_sec2 ceiling, so what we advertise is what an un-overridden move will use. The ceilings are never the effective value: clamp_velocity_limits applies them on the way in, so a configured 30 under a ceiling of 100 runs at 30, and publishing 100 would be a looser bound than the arm honors.

We snapshot at configure time rather than reading the live limits. set_speed_degs_per_sec via DoCommand therefore does not change what GetKinematics reports. That is intentional, not an oversight:

• The framesystem reads kinematics once when it builds the resource graph and never re-reads it, so live values would not reach the planner anyway.
• Publishing live values would only make RDK's two read paths disagree with each other, since armplanning.MoveArm fetches per call while the framesystem does not.
• It would also make the returned bytes change under anything hashing them.
• Publishing the configured value matches the yaskawa module, so the motion service gets the same meaning from both arms.

A consequence worth knowing: after DoCommand{"set_speed_degs_per_sec": 5} on an arm configured at 60, the document still reports 60 while MoveThrough/ToJointPositions plan against 5.

Testing

• test_to_sva_json_round_trips_via_parse extended to stamp per-joint-distinct limits (110-160 deg/s, 210-260 deg/s²) so a transposed or broadcast write fails, and to check position bounds survive.
• test_configured_zero_limits_are_published_as_zero pins the zero behavior in both the parsed optionals and the emitted JSON.
• test_unstamped_kinematic_limits_are_omitted checks an unstamped document has neither key.

make test green, -Wall -Werror clean, clang-tidy and clang-format clean.

🤖 Generated with Claude Code

[Andrew C. Morrow (acmorrow)]

I'm going to focus on this one first rather than the Yaskawa one, because I know this codebase better. Mostly questions at this point. It is a little tricky to review because I keep running into the limits of the current approach and seeing the problems, rather than seeing the gains we make by adopting what is here, despite the rough edges.

[Andrew C. Morrow (acmorrow)]

Above, these builder style methods are called apply_x, and I recommend continuing that pattern here: apply_kinematic_limits.

[Andrew C. Morrow (acmorrow)]

Presumably, if we have a value for one of these limits from the SVA, that's a true hardware constraint. Should it be possible to increase a limit here? Or should these be capped at what the SVA says the limit really is.

In other words, should we only allow the runtime alteration based on configuration to be a limit down move? Should it be an error to try to increase beyond what the SVA says?

And, what about limits as configured on the robot itself? I believe UR, for instance, offers on-device safety limits on position and velocity. How should those be handled? Should those be involved in our synthesized return?

[JohnN193]

I had intended to only consider the configured values for vel/acc to begin with, rather than having to update all the SVAs. I would rather not modify the actual SVAs just yet, but if its preferred I can try to find the numbers.

I think the short answer is yes, but I would rather save that kind of work for a future kinematics project. When talking with Dan we both felt that whatever we send over the wire should contain both the robot limit and the user's configured limit. That way if another application wants to modify the vel/acc limits they have all of the information to do so.

Def think at some point we should read from the limits configured on the robot to validate against, since we probably should already be doing that. I intended to make followup tickets for both xarm and ur to do so

[Andrew C. Morrow (acmorrow)]

What would such an unbounded velocity or acceleration mean, physically? Should we accept an SVA that constrains only a subset of the joints? I feel like either you know the limits, or you don't.

[JohnN193]

unbounded would mean that your planner should try to move the arm as fast as possible, hopefully with some other constraint in mind. leaving it unbounded could also work for a simulated environment.

In practice I needed some way to describe an optional state where trajex shouldn't be used for the motion service to grab, as we continue this kinematics work. Basically so arms that still using URDFs or aren't sending kinematic limits won't break in the motion service. the check I added to rdk checks if any of the joints are unset.

For this pr its both impossible to actually send unbounded joints, and in the ur module where the hardware has opinions on how fast motors can move I will go ahead and remove any sort of "unbounded" possibilities.

[Andrew C. Morrow (acmorrow)]

We are going to need, in the more complete kinematics project, a means to address caching. Consider, for instance, that an arm could be connected to physical arm 1 at a particular IP address, lose connection because that robot arm was taken out of service, and then regain connection to physical arm 2 at that same IP address because it is rotated into service to replace arm 1. The calibration on arm 2 could be different. Without a mechanism to have the arm module signal that kinematics may have changed, the client will be using the wrong one. If you are tracking work items for the next scope, I think it is important to get kinematics cache invalidation on the list.