Saved configuration walkthrough

What changed since you reviewed this robot setup?

You kept a configuration that you reviewed. Later, a controller file, calibration copy or source file changed. Before reusing that setup, compare the selected copies with the original baseline and read the actual differences. This guide covers the optional v1.5.0-shadow.12 evaluation prerelease; the workflow sends no robot commands.

Updated · RLSOK

Follow the saved-setup guide
01

Start with selected copies and an explicit review

Choose the source checkout and configuration files you actually intend to review. The published guide lists the required inputs for Piper, Metal, the selected SO101 hardware bridge, Beast, Cartesian and KUKA Sunrise workflows. These recipes describe particular source contracts, not universal support for every robot with a similar name.

Prepare and capture the selected setup, read the generated review material, and explicitly approve the first observation. Keep that baseline. Capturing a later observation must not quietly replace what you originally approved. The commands below assume those preparation steps are complete and observation-01.json is the copy you have reviewed.

rlsok profile approve-setup --observation observation-01.json \
  --actor YOUR_NAME --output baseline-01.json

rlsok profile review-setup --baseline baseline-01.json \
  --observation observation-02.json --output comparison-02
02

Read the values, not just a changed-file warning

Open comparison-02/report.md. The report includes before/after field values and excerpts of changed source lines. That gives the reviewer something specific to inspect instead of only a different hash.

For illustration, imagine a saved joint-order array changing from [joint_a, joint_b] to [joint_b, joint_a]. The names are the same, but their order is different. Array order participates in comparison. This is an explanatory example, not a captured robot result or a joint command to execute.

JSON/YAML key order and formatting do not change the semantic result. Joint maps, calibration values, modes, source code and unmapped settings do. File-byte differences and semantic differences remain distinct in the report.

03

Missing material is a result you need to see

In shadow.12, missing or malformed selected files and missing mapped fields remain visible in the report. An ambiguous device alias cannot be normalized into an unchanged match. Exit status 1 means review or material is needed; an invalid command/input can instead be an error with exit status 2.

ResultWhat it meansNext step
UNCHANGEDThe selected saved configuration matches the baseline within this comparison.Check whether those saved copies still represent the setup you intend to use.
REVIEW_REQUIREDThe comparison or inspection found something that needs review.Read the reported values, source excerpts and issue details before making a new approval.
NEEDS_MATERIALA required selected file or field is unavailable or invalid.Supply or correct that material, then capture again. Do not treat it as a match.
04

Inspect relationships before approving the first baseline

A consistent comparison can still preserve a problematic initial configuration. The separate inspect-saved-inputs command checks selected SO101, Beast and Cartesian file relationships before baseline approval. Read its report even when preparation says READY_FOR_REVIEW: that status means the selected files can be compared, not that a controller can start.

One concrete Beast example is the difference between watchdog_timeout in a YAML file and cmd_vel_timeout declared by the reviewed bridge source. Inspection flags that mismatch; it does not infer the bridge's live timeout or change the running node. Duplicate YAML keys are also reported instead of silently choosing the last value.

rlsok profile inspect-saved-inputs --recipe beast \
  --source /path/to/selected/Dons_Beast --input selected-files.json \
  --output inspection-01
05

Keep the boundary clear when you use the report

These commands read selected saved material. They do not start ROS, open a device, send a movement command or install a changed configuration. A saved inventory is evidence from its capture time, not proof of what is connected now. Matching calibration bytes also do not identify a physical robot.

UNCHANGED is not a motion permit, a live ROS check, a hardware-compatibility claim or proof of physical safety. Use the version-pinned guide below to prepare one supported selection and inspect the resulting report. Keep private calibration, device identifiers and customer files out of public posts.

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.