Navigation And Config

This page gives a high-level summary of the navigation side of the FYP codebase and points to the two more detailed subtopics:

• Navigation Config
• Navigation Manager Logic

1. Navigation Layer Split

In this repository, the navigation behavior is split into two parts:

• navigation ROS navigation stack configuration
• navigation_manager FYP-specific mission logic, floor switching, and localization control

The first part is mostly parameter tuning. The second part is where the strongest project-specific logic lives.

2. Navigation Config Package

The navigation package contains the costmap, planner, and move_base configuration.

Important files are:

• navigation/config/common_costmap_params.yaml
• navigation/config/global_costmap_params.yaml
• navigation/config/local_costmap_params.yaml
• navigation/config/move_base_params.yaml
• navigation/config/global_planner_params.yaml
• navigation/config/teb_local_planner_params.yaml

For the detailed explanation, see:

• reference/navigation-config.md

3. Frame Conventions In Navigation

The navigation config is not using the most generic ROS defaults.

For example:

• global map frame is map
• local costmap frame is camera_init
• robot base frame is aft_mapped

This matches the localization and mapping chain used elsewhere in the FYP system.

That means the navigation config is tightly coupled to the chosen TF structure. These values are part of the system design, not arbitrary YAML values.

4. Obstacle Representation

The current config uses:

• spatio_temporal_voxel_layer
• sob_layer

instead of a purely minimal 2D obstacle setup.

The obstacle source is:

• /cloud_registered

with:

• sensor_frame: aft_mapped
• height filtering
• voxel filtering
• finite obstacle range

This is consistent with a LiDAR-driven navigation pipeline and is clearly tuned for the current sensor and frame setup.

5. TEB Tuning

The local planner is:

• teb_local_planner/TebLocalPlannerROS

The parameters show that it has been tuned for a legged robot-like footprint and a fairly aggressive but bounded motion profile.

Examples:

• polygon footprint
• custom velocity and acceleration limits
• custom obstacle distances
• custom goal tolerances
• custom optimization weights

These are not generic tutorial settings. They are project-specific deployment choices.

6. Navigation Manager As The Main Custom Layer

The package:

• navigation_manager

is where the repository becomes distinctly different from a simple ROS navigation example.

The most important files are:

• navigation_manager/scripts/floor_manager.py
• navigation_manager/scripts/hdl_killer.py
• navigation_manager/scripts/stair_climber.py
• navigation_manager/config/waypoints.yaml
• navigation_manager/launch/start_nav_logic.launch

For the detailed explanation, see:

• reference/navigation-manager-logic.md

7. floor_manager.py

floor_manager.py is the central multi-floor mission controller.

It does the following:

• loads waypoints.yaml
• stores floor definitions and stair edges
• routes between floors using the configured stair graph
• sends normal move_base goals to stair approach points
• triggers the stair climbing service
• publishes z_offset after a floor transition
• switches the floor map after climbing
• continues navigation toward the final floor goal

This is the core reason the project is more than a single-floor navigation demo.

8. hdl_killer.py

hdl_killer.py is another strong FYP customization.

Its responsibilities include:

• reading start candidates
• publishing initialization poses
• monitoring scan matching quality
• deciding when localization is sufficiently stable
• freezing the localization TF when appropriate
• applying a received floor-dependent z_offset

This makes the localization pipeline behave more like a managed mission component than a passive state estimator.

9. waypoints.yaml

The file:

• navigation_manager/config/waypoints.yaml

is not just a list of goals. It is the mission model.

It contains:

• floor-specific map names
• stair poses for each floor
• goal poses for each floor
• floor-to-floor stair edges
• per-floor height offsets
• startup floor settings
• candidate initial poses

This file is the bridge between raw maps and runnable multi-floor behavior.

10. start_nav_logic.launch

The file:

• navigation_manager/launch/start_nav_logic.launch

ties together:

• map_server
• hdl_killer.py
• stair_climber.py
• floor_manager.py

It also defines:

• initial map file
• initial floor
• initial target floor
• initial target key
• stair climbing parameters such as half_height and full_height

So this launch file is the runtime summary of the whole multi-floor logic layer.

11. Why This Package Matters

Compared with upstream mapping and localization packages, this navigation layer is where the repository becomes a complete application.

Without navigation_manager, the system would still have:

• mapping
• localization
• move_base

But it would not have:

• floor switching
• stair edge routing
• localization freeze-and-compensate behavior
• map switching between floors
• a structured mission from one floor goal to another

That is why this package should be treated as one of the main original engineering contributions in the FYP repository.