Korea STA
Every version of the robot's parameter file, dated, with what moved between one and the next.
37 versions across 2 configurations.
Nav2 navigation stack
32 versions
The navigation parameter file as it runs on the AMR — planners, controllers, costmaps and the collision monitor.
Latest 2026-09-28-v21 Sept 2026 — 28 Sept 2026
AMCL stack
5 versions
The localization parameter file as it runs on the AMR — the odometry motion model, the particle filter, the laser likelihood field and global relocalization.
Latest 2026-09-19-v11 Sept 2026 — 19 Sept 2026
Checklist
19 test cases
The driving accuracy and stability test plan for the AMR — what is to be run, on which node, under which conditions, and what it has to hit to pass.
113 runs prepared7 Sept 2026 — 14 Sept 2026
Corner smoother
3 cases
An AMR follows two graph edges through a corner. Whether the smoother lays down the arc, cuts a chord, or stops and turns depends on where the robot is when it gets there.
Interactive diagramt = R · tan(δ/2)
Design changes
28 changes
What has to change, and in what order, to take a general goal from 15 cm / 5° to 5 cm / 2° and stop the robot weaving along the path.
15 items across 3 phases5 cm / 2°
Controller parameters
231 parameters
What every controller_server parameter on the AMR does, read from the source it configures, with the comments the parameter file carried beside each one.
348 comment lines kept10 comments disagree with the codehmc_nav2_params_tuning_18Sep.yaml
What this is
Tuning a navigation stack is a long argument with a hundred numbers. A weight goes up, tracking improves, something else starts oscillating; three weeks later the file looks nothing like it did and nobody can say which change bought which behaviour.
This page is the record. Each version is a whole parameter file as it ran on the robot on a given day, kept verbatim, and everything else here is derived from comparing them: what was added, what was removed, what moved, and what the comment beside it said at the time.
How to read it
A version is named by the day it was in force and which upload of that day it
was — 2026-09-02-v1, then 2026-09-02-v2 if the afternoon went differently
from the morning. The date is the robot’s, not the upload’s: a file recorded the
morning after a session still belongs to the session.
What moved is the table to read first. One row per parameter that changed at least once over the period, showing the values it took and the version each one started at. A parameter set once and never touched again is not in it — those are counted, not listed, because a file of six hundred parameters where four were tuned is a page about four parameters.
Two things are worth knowing about how changes are counted:
- A value is compared as written.
900.0and900are a real change, because ROS 2 types a parameter from how it is spelled and a node that wants a double will refuse an integer. Only the spelling of booleans is normalised, sincetrueandTruemean the same thing everywhere. - A comment moving is not a value moving. These files carry their own
history in the margin —
cost_weight: 25.0 #### 10.0, 24.7832, 13.0— so an edit to the note beside a number is shown, and counted separately, rather than reported as a re-tune.
Commenting a parameter out reads as a removal, and uncommenting it reads as an addition. That is deliberate: a commented-out line is not in force, and the question this page answers is what the robot is actually running.
What this is not
It is not a configuration source. Nothing here is deployed from, nothing reads it at runtime, and a version being on this page is not a claim that it is currently on any robot. It is a log — the file, the date, and what changed.
It is also not complete by construction. A version exists here because somebody uploaded it, so a configuration that ran for a day and was never recorded is simply absent, and the gap will not announce itself. The dates are the only guide to how continuous the record is.