FixTheRobot Explore Robotics / Navigation / M9 / M9-L2

This lab works on phones, but writing code is much easier on a laptop.

Navigation · Navigation in the Real World · M9-L2 · Advanced

Lint a Nav2 Parameter File

Incident report · Meridian General Hospital

10:05. The new Scout unit boots, the costmaps appear in the visualiser, and the first goal is rejected with a transform timeout. A second unit starts, drives, and then stops with "failed to make progress" while the wheels are turning. Both run the same 300-line parameter file, copied from the last site, edited by four people.

Reading 300 lines for a contradiction is slow and error-prone. You will write the small linter that does it in a second, and learn which relationships a parameter file has to satisfy.

Your task

    Simulation
    solution.pyLoading Python…
    Ctrl+Enter runs
    What Python can I use?

    Plain Python with math and heapq. The file arrives as the nested dict params; the starter code includes leaves(params), which flattens it into dotted paths such as amcl.ros__parameters.use_sim_time. No YAML or XML modules are available or needed. Your code runs in a background worker and is never sent anywhere.

    Hints

    What this lab teaches

    A navigation stack is configured by dozens of numbers and names spread over many nodes, and most of the damaging mistakes are not wrong values but values that disagree: a clock that is simulated in one node and wall time in another, a base frame spelled two ways, two costmaps with two footprints, a controller that asks for a speed the velocity smoother will never allow. Each such mistake is cheap to find by a program that reads the file and cheap to miss by a person.

    The page has no paste-in text box, so each stage gives your Python the parameter file already parsed into nested dictionaries (the text of the practice example is shown on the page, and the same parser produced the dictionaries). You write lint(params, facts) and return a list of findings, each naming a rule and the dotted path of one involved setting. Grading is result-based on hidden files: some have several problems, some have none, and some contain unusual but valid settings that a careless linter would flag.

    The setting names used here (FollowPath, inflation_layer, progress_checker, velocity_smoother and so on) follow the structure of the Nav2 parameter files, but parameter names and defaults change between releases, so check the documentation for your distribution. The rules are this lab's rules; they are examples of the kind of check a real linter makes.

    Theory for this lab

    Navigation in the Real World labs

    1. M9-L1: Tune the Inflation Radius
    2. M9-L2: Lint a Nav2 Parameter File: this lab.
    3. M9-L3: Validate a Behavior Tree
    4. M9-L4: Bring Up Nav2 in Simulation

    Educational simplification: the parameter files are generated, much shorter than a real Nav2 file, and parsed by a small YAML reader that handles only what these files use; the footprint string of a real file is already converted to a list of points; and the rules are this lab's own (the 10 cm rule, for example, is a design limit, not a Nav2 requirement). A real linter must also handle your release's names, defaults and plugins.

    Get the next lab

    Get notified when new robotics labs are released. One email per new lab, nothing else.