What tuning notes actually survive across sessions, payload changes, and new tools when working with OpenArm MIT control?
This thread is for advanced OpenArm builders and integrators working with MIT control gains.\n\nWhat exact notes do you record when adjusting gains, and what patterns tell you a setting is unsafe even before a full failure happens?\n\nIf you reply, include one observable symptom and one rollback step.
The mistake is not aggressive tuning by itself. It is aggressive tuning without enough context to safely undo the change the next day.
Good tuning notes always include loop rate, payload state, visible oscillation, and the first change that made the run feel unstable.
If you already have a tuning worksheet, share the smallest version another team could adopt immediately.
Pick your closest symptom to follow the right troubleshooting path.
Use synchronized logs and one-variable-at-a-time replay around "[OpenArm] MIT control gains for builders integrators (advanced)" to separate mechanical, model, and control contributors.
python tools/log_signals.py --task repro_case --duration 120
python tools/analyze_trace.py --input trace.json --report summary.mdUse measurable thresholds from replayed stress cases, and block deployment if any fail under warm-state conditions.
Use them as a checklist template first. Confirm interface names, fixture IDs, and safety conditions in your own cell before execution.