Configuration notebook

Which settings did you use before the last change?

You change a tracker parameter, edit some code, then come back a few days later. Remembering which files belonged together gets harder than remembering the parameter itself. Here is a small way to keep that record: save one reviewed setup, change one value, and compare the new copy with the original.

Updated 2026-09-15 · RLSOK

Download and try the example

What you will try

This example uses the public Pioneer-X source and RLSOK Local Check 1.5.0. You will change lookahead_distance from 0.6 to 0.7 in a saved Pure Pursuit JSON file. The report should show that exact difference while leaving your original baseline alone.

These are example values taken from source defaults, not a robot owner's current settings or recommended tuning values. The exercise reads and copies files. It does not start ROS, connect to a robot or measure how well it follows a path.

Use Ubuntu 22.04 or 24.04 x64 with Python 3 and Git installed. Download and extract Local Check from the download page, then open a terminal in its directory. A cloud account is not needed. The linked version 1.5.0 guide keeps these commands and materials together.

Put the files together

First, select the saved settings and firmware source. The helper records those choices; preparation copies the related host source as well. Keeping the source revision fixed makes the example reproducible.

export PATH="$PWD/bin:$PATH"
git clone https://github.com/DaneelOlivawXJose/pioneer-ros2-diff-drive.git Pioneer-X
git -C Pioneer-X checkout 39f67a0697f8b28669c26edfe5ca2124348756d7
cp materials/pioneer-pure-pursuit-source-example.json tracker.json
python3 materials/pioneer-selection.py --source ./Pioneer-X \
  --settings tracker.json --firmware Pioneer-X/firmware/esp32_code/esp32_code.ino \
  --output selected.json
rlsok profile prepare-saved-setup --recipe pioneer-x \
  --source ./Pioneer-X --input selected.json --output setup-01

Keep the starting point

Open setup-01/REVIEW.md and look through the selected files before keeping a baseline. source-files.json maps the copied source IDs to their original paths. Use your own name in place of YOUR_NAME below.

Approve here means choosing a reference for later file comparisons. It does not authorize a drive command, and the reference does not need to be replaced every time you experiment.

rlsok profile capture-setup --manifest setup-01/manifest.json --output observed-01.json
rlsok profile approve-setup --observation observed-01.json \
  --actor YOUR_NAME --output baseline-01.json

Change one value and compare

Open tracker.json in your editor. Change only lookahead_distance from 0.6 to 0.7 and save it. Prepare a second copy, then compare it against baseline-01.json. Use the new output names below so the first copy remains available.

rlsok profile prepare-saved-setup --recipe pioneer-x \
  --source ./Pioneer-X --input selected.json --output setup-02
rlsok profile capture-setup --manifest setup-02/manifest.json --output observed-02.json
rlsok profile review-setup --baseline baseline-01.json \
  --observation observed-02.json --output comparison-02

Read the reason, not just the label

Open comparison-02/report.md. For this deliberate edit, expect REVIEW_REQUIRED and the lookahead change, 0.6 → 0.7. That says the saved setup changed. It does not say 0.7 is better, worse or safe for a particular robot.

UNCHANGED means the selected files still match. NEEDS_MATERIAL means a copied file is missing or cannot be read correctly. During preparation, missing settings or unsupported algorithms are rejected before a usable setup is created. A failed comparison is not a reason to approve a new baseline blindly.

The release includes offline checks of the unchanged example, a lookahead edit, source edits and an algorithm switch. Those checks use public source and deliberate file changes. They are not driving tests.

When you use your own files

For this Pioneer-X workflow, replace the example with your saved /web/settings/algoritmo JSON body and select the firmware source you actually want to compare. Keep local firmware copies and reports private if they contain WiFi settings. The public repository does not contain the robot's current SCADA settings.

The recipe covers saved PURE_PURSUIT and MPC selections. The reviewed CARROT/PROPORTIONAL path has an unresolved topic and settings mismatch, so this recipe refuses it. See the source guide for the exact fields and limitations.

A saved firmware file cannot prove which binary is flashed. A matching report cannot tell you which node is publishing cmd_vel right now. Check those separately before drawing conclusions about a running robot.

For a first attempt, stop after opening the report and finding the changed field. If that fails, share the command that failed and a short error with private details removed in the linked GitHub discussion.

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.