Navigation Manager Logic

This page explains the custom logic inside navigation_manager. This package is one of the main original engineering layers in the FYP repository.

1. Why This Package Exists

The standard ROS navigation stack can plan and execute navigation on a map, but it does not by itself solve the full FYP problem:

• switching between floors
• deciding which staircase to use
• reloading floor-specific maps
• adjusting localization after a floor change
• coordinating stair-climbing behavior

That is why navigation_manager exists.

2. Main Files

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

3. floor_manager.py

floor_manager.py is the central mission controller.

It does the following:

• loads floor and waypoint configuration from waypoints.yaml
• stores available floors and stair edges
• computes a route from the current floor to the target floor
• sends move_base goals to stair approach points
• triggers the stair climbing service
• publishes floor-dependent z_offset
• switches map files when the robot reaches a new floor
• continues to the final goal on the destination floor

This script is what turns separate floor maps into one mission-level navigation system.

4. waypoints.yaml

The file:

• navigation_manager/config/waypoints.yaml

contains the mission model.

It stores:

• map names for each floor
• stair poses
• floor goals
• stair-to-stair floor edges
• height offsets
• initial floor settings
• candidate initialization poses

This file is not only navigation data. It is the structured representation of the building layout as the robot understands it.

5. hdl_killer.py

hdl_killer.py is a strong FYP-specific localization management layer.

Its responsibilities include:

• loading start candidates
• publishing trial initial poses
• monitoring HDL scan-matching status
• deciding when localization is healthy enough
• freezing the localization TF when needed
• applying z_offset after floor transitions

This means localization in the FYP is not treated as a passive backend. It is actively managed as part of the mission flow.

6. stair_climber.py

stair_climber.py is the execution layer for actual stair traversal.

It is environment-dependent. That is why the new-environment workflow must explicitly check whether the current stair strategy still matches the building.

For example:

• straight stairs may work with the current logic
• U-shaped stairs may require the historical alternative strategy you referenced from commit 17b344c

So this script is part of the motion policy for floor transitions, not just a helper.

7. start_nav_logic.launch

The file:

• navigation_manager/launch/start_nav_logic.launch

starts and connects:

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

It also defines runtime mission parameters such as:

• initial map file
• initial floor
• initial target floor
• initial target key
• stair height and timing parameters

This launch file is therefore the runtime summary of the multi-floor logic layer.

8. Why This Package Is A Major Contribution

Compared with upstream mapping and localization repositories, this package contains some of the most project-specific logic in the entire FYP.

Without it, the repository would still have:

• mapping
• localization
• move_base

But it would not have:

• multi-floor mission routing
• floor-specific map switching
• stair edge traversal logic
• localization compensation after climbing
• mission-level coordination from start floor to destination floor

That is why navigation_manager should be treated as one of the main original engineering contributions in this project.