Tune and validate control
Result: accept settings against measured criteria rather than one successful movement. First verify calibration, the initial motion path, profiles and any gravity model.
1. Prepare a baseline plan
macOS / Linux
cp tools/tuning/example.json tools/tuning/plan.local.json
cp tools/tuning/controller.example.json tools/tuning/controller.local.json
Windows PowerShell
Copy-Item tools/tuning/example.json tools/tuning/plan.local.json
Copy-Item tools/tuning/controller.example.json tools/tuning/controller.local.json
In tools/tuning/plan.local.json, set config to controller.local.json, stage to baseline and candidates to []. The source example contains a PID candidate; do not run it unchanged as a baseline measurement.
Set the controller port and profiles, and include every supporting motor in joints as {"followerId": ID}. Remove a copied durationMs: the plan’s batch.maxDurationMs owns the duration budget.
| Plan field | Decision before running |
|---|---|
probeId |
Motor that will move |
poses.screen, poses.validate |
Different permitted endpoint pairs for screening and validation; do not copy example counts 2000/2050 without checking physical positions |
motion.speeds |
Speeds appropriate for the reviewed load |
limits |
Following/support error, temperature and voltage limits |
acceptance |
Error, overshoot, settling and saturation criteria |
batch |
Repeats, hold durations and total budget |
Positions are corrected encoder counts. After recalibration, the same numbers may represent different physical positions. Supporting joints keep existing hold targets; the tool does not automatically reposition the whole arm.
2. Separate the three commands
Inspect files and estimated bus use without connecting:
macOS / Linux
npm run tune -- inspect tools/tuning/plan.local.json
Windows PowerShell
npm.cmd run tune -- inspect tools/tuning/plan.local.json
Read firmware, calibration, limits and profiles without changing motors:
macOS / Linux
npm run tune -- preflight tools/tuning/plan.local.json
Windows PowerShell
npm.cmd run tune -- preflight tools/tuning/plan.local.json
Run the batch with movement:
macOS / Linux
npm run tune -- run tools/tuning/plan.local.json
Windows PowerShell
npm.cmd run tune -- run tools/tuning/plan.local.json
Do not run if preflight reveals unexpected clipped targets, a model error or an endpoint pair collapsed to one position. The batch moves probeId; other motors must retain a reviewed supporting pose.
3. Tune in order
- Baseline: initial movements and holds without candidates; establish repeatability and investigate alarms.
- Gravity: check a model across poses, directions and at least two speeds. This stage collects data without changing gains.
- Velocity: compare directional feedforward using steady movement.
- PID: compare P, D and filtering across loads; use longer holds to expose oscillation.
- Integral: introduce only for a lasting error; test gain and limit together, including small reversals.
- Motion: hold gains fixed while comparing acceleration and ramp time.
- Combined motion: replay a whole-arm path; isolated joint tuning does not validate coupled movement.
- Validation: freeze settings and check required speeds, accelerations, payloads and extended holds.
The stage restricts candidate fields. Baseline, gravity and validation do not change settings. Total output limits remain explicitly configured rather than automatically tuned.
4. Interpret results
Each tools/tuning/logs/<run>/ directory contains events.ndjson and summary.json. Review completion status, baselines before and after the batch, independent validation pairs and every acceptance criterion. An incomplete or failed batch provides no recommendation. Baseline drift can make a comparison inconclusive.
Metrics cover moving tracking RMS, steady error and span, overshoot, settling time, total response time and saturation fraction. Settling requires a continuous interval inside the band; an early crossing is insufficient. Short holds cannot establish the absence of slow oscillation.
Normal completion restores the configured baseline and retains hold. Ctrl+C during tuning attempts torque-off, unlike Extension replay. Support the mechanism before interruption; a killed process or disconnected bus can leave the previous hold active.
5. Save accepted settings
The tool does not automatically install a winning candidate. After review, update local profiles and keep them with calibration, model, payload/mounting details and validation logs. The export below uses the named-pose controller from the first-motion guide. Update its profiles to the accepted values. To use apply, first add this top-level joints property to tools/poses/controller.local.json, adjusting the IDs to match the physical arm:
"joints": [
{"followerId": 1}, {"followerId": 2}, {"followerId": 3},
{"followerId": 4}, {"followerId": 5}, {"followerId": 6}
]
This is a property fragment, not a complete JSON file: add a comma between it and the adjacent property. Export to a new directory without connecting to motors:
macOS / Linux
npm run tune -- export tools/poses/controller.local.json accepted-controller
Windows PowerShell
npm.cmd run tune -- export tools/poses/controller.local.json accepted-controller
Use a directory that does not exist yet. Export does not certify settings. To apply the exported controller without replay, it must contain joints for all followers. This command changes control and enables hold:
macOS / Linux
npm run tune -- apply accepted-controller/controller.json
Windows PowerShell
npm.cmd run tune -- apply accepted-controller/controller.json
A profile change can briefly release torque. Ordinary replay applies its own configuration and does not require a separate apply command.
Documentation home · Source revision: a995f77. Extension 9.0.