Does the active ROS 2 controller still match the approved setup?
Compare a fresh observation of the selected controller with the original approved configuration. A YAML file alone cannot show which running controller owns the joint interfaces. RLSOK can record the difference locally without sending a motion command.
Updated · RLSOK
Get the local evaluation prereleaseScope and prerequisites
This procedure uses RLSOK v1.5.0-shadow.8, installed in a separate evaluation directory, and the documented so101-arm or trik-drive source mapping. It requires your existing ROS installation and an isolated graph with physical controllers unreachable.
Prepare the inspected source checkout, expanded URDF, reviewed runtime settings, discovered catalog and one local command example using the source-workspace guide. Review differences from the mapping's pinned source. The mappings do not establish official robot support or a customer's deployed configuration.
Export the selected controller state
For the documented root-namespace SO-101 arm mapping, export the selected controller as shown below. The TRIK mapping instead selects diff_drive_controller and /diff_drive_controller. Use the exact manager and node from your reviewed environment.
The exporter uses ListControllers, ListParameters, GetParameters and local graph queries. It does not switch controllers, set parameters or send goals. It checks controller metadata around the parameter reads and refuses a detected change; this is not an atomic or authenticated hardware snapshot.
rlsok profile export-controller --manager /controller_manager \ --controller arm_controller --node /arm_controller \ --output baseline-controller.json
Prepare and approve the baseline
Follow the source-workspace guide's prepare-source procedure with your actual files and --controller-state baseline-controller.json. Preparation requires a fresh, active controller matching the recipe's type and joint interfaces. SO-101 also requires the selected node to host its trajectory action.
Inspect profile.json, the copied files, mappings and command example before the separate local approval step. Preparation does not create approval. Local approval is not Hosted authentication or execution permission.
Before the baseline capture, re-export the controller state and refresh the workspace with the actual source, expanded URDF, settings and --controller-state file. Stop after a refresh error. Use the detailed guide for the complete input arguments.
# From the prepared workspace, after successful refresh: rlsok profile capture --profile profile.json --output baseline.json
Observe the reviewed change without replacing approval
Review a configuration change in an isolated setup. A copied YAML edit demonstrates file drift; it does not demonstrate an active controller swap. When checking an actual software-controller change in simulation, export the same selected controller again to changed-controller.json and pass it to refresh-source.
Keep the original profile, approval and command example. A later export may show the controller inactive or absent; preserve the observation so the evaluator can identify the mismatch. Re-export before each capture, use new output filenames, and keep both observations within the profile's five-minute freshness window.
# After refreshing all changed inputs and the fresh controller export: rlsok profile capture --profile profile.json --output changed.json rlsok profile compare --profile profile.json --approval approval.json \ --baseline baseline.json --changed changed.json --proposals proposals.json \ --output comparison
Read the reason as well as the decision
Resolve each fact ID through profile.json and retain both observations and the readable report. Do not edit timestamps, insert expected values into observations or approve the changed setup to make a negative comparison disappear.
| Observation | Interpretation |
|---|---|
| Baseline WOULD_ALLOW | The declared local checks passed for that observation; no execution permit or physical-safety conclusion |
| Changed WOULD_BLOCK with fact_mismatch:active-controller | The observed active-controller fact differs from the original approved value |
| Stale observation or missing coverage | A distinct reason for blocking; it does not by itself prove the intended configuration change |
Reported result and remaining limits
The v1.5.0-shadow.8 release notes report two local software-controller comparisons: an installed JointTrajectoryController using the public SO-101 five-joint parameters, and an installed DiffDriveController using the public TRIK wheel parameters. Both used GenericSystem mock hardware. Replacing the selected controller on the same joint interfaces changed a matching baseline to WOULD_BLOCK with fact_mismatch:active-controller while approval, profile and example stayed unchanged.
Those checks sent no motion command. They are developer-run mock-hardware results, not customer case studies, physical SO-101/TRIK validation, Gazebo dynamics or proof of Humble compatibility. The export cannot authenticate attached devices, firmware, calibration, compiled binaries or future execution.
Sources and verification scope
Source code and guides describe implementation and setup. Release notes identify reported checks and their limits. Publication alone does not establish customer use or physical-robot validation.
Continue with the relevant guide
Try the local example without an application. For setup or integration help, you can also contact us.