An important info about the structure of the code.
The code is divided in two sections: open access and by subscription
The first part of the code for this section is located both in landscape_designer part of an archive Note that in addition to landscape_designer, the archive includes some additional folders, like maps and worlds, that are used by all projects and therefore are located outside of them. An archive has proper directory structure, so all you have to do is expanding it.
Also note that currently the ROS2 Humble is used. However, older sections of this tutorial still use Galactic and maybe some older versions. I will fix it in future.
For installation instructions, see Installation.
As for the second part: the tutorial is divided in two parts, too. First part is about the theory, it is complete and free (see below).
The code itself however has either free access, or by subscription, like some utilities that live in "utils_commercial" folder. When you try to access these utilities, you will be asked to log in.
Additionally, Kalman part of that code is moved to a by-subscription section as well:
kalman_nav.zip.
Note: This archive should be added to same folder where you have unpacked
archive.
Let me explain how Kalman code works and why do you need commercial code if free code works just fine.
A kalman.py file was moved to by-subscription section and therefore will not be available unless you get it and copy it over to nav25d_06/nav25d_06 (or later) folder. The (free) Navigation.py file checks if this file is present and either uses it (in which case you will get a complete Kalman based localization) or not (in which case Kalman filter is replaced with a rather primitive simulation).
As the result, in a Gazebo simulator, all future demos will work even without by-subscription files. But of course, in a real world your robot will not have these localization abilities.
Important note: as I write more sections, the kalman_nav.zip file will get additional context. Once purchased, it gives you 1 year of access, so when, for example, I add support for aruco markers in Gazebo (available already) or make the navigation to respect the fact that the world is round, or whatever else related to localization - it will go to this archive and will be available with the same subscription. Unless this project is terminated, of course.
As for utilities that are available from by-subscription section, they do not affect simulation, but give you tools to design the world, control robot in a simulation and provide some other nice-to-have features.
Earlier (when working with Nav2 module) I have introduced the Path Follower. Please refer to the corresponding chapter (or to links section below) for theory. The idea is very simple: the algorithm finds a point on a path that is ahead of a robot and moves towards it. As it gets closer, a new point is selected and so on. This algorithm is also called Pure Pursuite Path Follower
Of course, some additional euristics are required, for example, it there is a sharp turn ahead, we need to reduce the speed and look for a point that is closer to a robot.
In this section we will create a fully functional Path Follower for our 2.5d world. It will rely on localization data from our Kalman filter that performs sensor fusion, and it will send commands to our robot, so it follows the path.

Note that, while being a must for any robotic library, Path Follower is not a universal solution. Let me show an exagerated (by playing with parameters) result of "path following":

What happened? Our path follower is only as good as localization data is: if the robot's position and orientation info "jumps", the robot will move in the wrong direction. Then it will correct itself, which can produce rather signifficant deviations from a path.
So what do we do? If you run the example, you will notice that the robot leaves the road, sometimes on the very steep areas, which is not safe. Also, if we let it drive like that, the road police might have some questions...
This is why we use "global" and "local" algorithms in robotics. I will use "local" algorithm to fix the problem in future, for now just keep in mind that we should do what humans usually do: create an accurate local map (say, within the visible range) and move there, using global localization data for high level guidance only. A good example would be using odometer, as - without slippage - it gives us an accurate positioning. But as it does slip, we will probably use some other navigation technics. A human would probably say something like "this tree is in the right direction, so I am going there and then look at a compass again". Robot can do the same.
Once again, the Path Following algorithm will still be used, but the robot will use additional local navigational tricks to improve its positioning.