[Other issue]: Phase-Aware Route Validation Implementation - Request for Review and Feedback

[rajgavhalerg-creator]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

Description

Dear RMF Development Team, I hope this email finds you well. I am writing to share an implementation I've developed for phase-aware route validation in RMF and to seek your feedback on the approach and potential integration into the main codebase. Background I was working on a delivery task scenario where I needed to dynamically exclude specific waypoints during the dropoff phase only, without affecting the pickup phase or other robots in the fleet. The requirement was: Exclude 2-3 specific waypoints during dropoff phase planning Allow normal navigation during pickup phase Apply exclusions per-robot, not fleet-wide Maintain the static navigation graph (0.yaml) unchanged Implementation Approach I implemented a custom PhaseAwareRouteValidator that extends the existing RouteValidator interface. The key components are: 1. Phase Detection Added DeliveryPhase enum to RobotContext to track current task phase Modified Delivery.cpp to set phase during TransferItems::standby() Updated TaskManager.cpp to clear phase upon task completion 2. Custom Route Validator Created PhaseAwareRouteValidator inheriting from rmf_traffic::agv::RouteValidator Implemented coordinate-based waypoint exclusion with configurable tolerance Added phase-aware validation logic that only applies exclusions during dropoff phase 3. Integration Points Modified SearchForPath to use the phase-aware validator Updated FindPath service to pass RobotContext to the validator Extended the RouteValidator base class with a custom_validation() hook

Key Files Modified
src/rmf/rmf_ros2/rmf_fleet_adapter/
├── include/rmf_fleet_adapter/agv/
│ ├── RobotContext.hpp (added DeliveryPhase enum)
│ └── PhaseAwareRouteValidator.hpp (new file)
├── src/rmf_fleet_adapter/agv/
│ ├── RobotContext.cpp (phase management methods)
│ └── PhaseAwareRouteValidator.cpp (implementation)
├── src/rmf_fleet_adapter/tasks/
│ └── Delivery.cpp (phase setting during TransferItems)
├── src/rmf_fleet_adapter/jobs/
│ └── SearchForPath.cpp (validator integration)
└── src/rmf_fleet_adapter/services/
└── FindPath.cpp (RobotContext passing)
Results and Testing
The implementation successfully:
✅ Detects delivery phases correctly (pickup vs dropoff)
✅ Rejects routes passing through excluded waypoints during dropoff phase
✅ Allows normal navigation during pickup phase
✅ Works per-robot without affecting other fleet members
✅ Maintains compatibility with existing RMF infrastructure

Questions for the Development Team
Architecture Review: Is this approach aligned with RMF's design principles and extension patterns?
Integration Potential: Would this be a valuable addition to the main RMF codebase as a configurable feature?
Performance Considerations: Are there any performance implications of the coordinate-based validation approach?
Alternative Approaches: Are there other recommended ways to achieve phase-aware route modifications in RMF?
Testing Recommendations: What additional testing scenarios should be considered for this feature?
Technical Details
The implementation uses coordinate-based validation with a configurable tolerance (currently 1.0m). The validator checks each trajectory waypoint against excluded coordinates and rejects routes that pass too close to excluded waypoints during the dropoff phase.

Through this approach, I still do not get the desired result during the drop-off phase, as the robot is not avoiding the excluded waypoints. Are there any solutions for this?

[mxgrey]

Sorry for how long it took to reply. This is a much deeper technical topic than we usually get, so I wanted to make sure I could give it undivided attention while I try to understand your proposal.

You've done an excellent job of dissecting the existing code base and finding the right places where modifications could conceivably be made.

Architecture Review: Is this approach aligned with RMF's design principles and extension patterns?

If we intended to keep developing new features and extension points on the existing code base, then you have nailed the "right" way to implement this. Unfortunately I've found that the code base as it exists today is so complicated that trying to expose any extension points will likely lead to a lot of user errors, confusion, and broken behavior. Mostly because of the complexity of rxcpp and the danger of managing memory in C++.

That's why we're doing a rewrite of the code base where we separate out modules via ROS interfaces and we'll define behaviors using the crossflow library which we're developing.

Integration Potential: Would this be a valuable addition to the main RMF codebase as a configurable feature?

Given the fact that we're trying to migrate off of this code base, I'm reluctant to officially add this kind of extension point because there's a risk it will increase our maintenance burden when we have to handle bug reports or requests for help when users start experimenting with the additional features.

That being said, I recognize that your use case is valid and worth supporting. I also recognize that it's not reasonable for me to insist that you wait until the next generation work is finished before Open-RMF can support it, especially since you have a workable solution with the existing code base.

As a compromise, I would be open to adding the necessary extensions to the unstable API. This could allow you to get the extension points that you need without forking the code base. At the same time, it should be clear to the general community that they are using these extensions at their own risk without any guarantee of support.

Performance Considerations: Are there any performance implications of the coordinate-based validation approach?

If the route validator were provided semantic information about the route (e.g. the waypoint names / indices) then it could probably be made more efficient, but that would be a more disruptive change.

Through this approach, I still do not get the desired result during the drop-off phase, as the robot is not avoiding the excluded waypoints. Are there any solutions for this?

If the route validator is set correctly to eliminate routes that pass through the excluded waypoints then I don't have an explanation for why it wouldn't work. I would recommend double-checking that you're always excluding routes which pass through those waypoints, e.g. check that the whole continuous length of the trajectory is avoiding the excluded waypoints, not just that the trajectory's discrete waypoints don't overlap with the excluded waypoints.