|
||
---|---|---|
.devcontainer | ||
.vscode | ||
analysis | ||
results | ||
src | ||
.gitignore | ||
.gitmodules | ||
colcon_defaults.yaml | ||
Dockerfile | ||
README.md | ||
setup-venv.sh |
Dynamic Priority Scheduling for ROS-EDF Executor
This repository contains experiments for the ROS-EDF executor with priority-based and deadline-based scheduling capabilities.
Usage
Clone with submodules enabled:
git clone --recurse-submodules https://github.com/user/ROS-Dynamic-Executor-Experiments.git
Make sure you have sourced your ROS 2 environment.
Run the example:
ros2 run casestudy casestudy_example
Then run the analysis notebook:
jupyter notebook analysis/analysis.ipynb
Dynamically Adjusting Scheduler Approaches
The PriorityMemoryStrategy supports different scheduling policies for ROS callbacks. To extend it with dynamically adjusting scheduling that reacts to semantic events, there are several viable approaches:
Approach A: Custom PriorityExecutableComparator
Replace the existing comparator with a custom implementation:
Pros:
- Direct control over scheduling logic
- Clean separation of concerns
- Can implement complex scheduling policies
- Doesn't require modifying deadline values
Cons:
- Requires understanding and maintaining the comparison logic
- May need to add new fields to PriorityExecutable to track dynamic priorities
- Could become complex if multiple factors affect priority
Approach B: Dynamic Deadline Adjustment
Keep the EDF comparator but adjust deadlines based on priority logic:
Pros:
- Works within the existing EDF framework
- Conceptually simple - just manipulate deadline values
- Doesn't require changing the core sorting mechanism
- Easier to debug (you can log deadline changes)
Cons:
- Potentially confusing semantics (using deadlines to represent non-deadline priorities)
- May interfere with actual deadline-based requirements
- Could lead to instability if not carefully managed
Approach C: Event-Driven Priority Field
Add a dynamic boost factor field to PriorityExecutable:
int dynamic_priority_boost = 0;
Then modify the comparator to consider this value:
if (p1->sched_type == DEADLINE) {
// First compare deadline as usual
// Then use dynamic_priority_boost as a tiebreaker
if (p1_deadline == p2_deadline) {
return p1->dynamic_priority_boost > p2->dynamic_priority_boost;
}
return p1_deadline < p2_deadline;
}
Pros:
- Clearer semantics than manipulating deadlines
- Keeps deadline scheduling intact for real-time guarantees
- Easy to adjust at runtime
Cons:
- Requires modifying both PriorityExecutable and comparison logic
Approach D: Priority Multiplier System
Implement a system where chains can have priority multipliers applied:
float priority_multiplier = 1.0f;
And then in the comparator:
// For priority-based scheduling
int effective_p1 = p1->priority * p1->priority_multiplier;
int effective_p2 = p2->priority * p2->priority_multiplier;
return effective_p1 < effective_p2;
Pros:
- Scales existing priorities rather than replacing them
- Preserves relative importance within chains
- Intuitive model for temporary priority boosts
Cons:
- May need to handle overflow/boundary cases
- Requires careful tuning of multiplier ranges
Recommendation
Approach C (Event-Driven Priority Field) offers the best balance of:
- Clean semantics
- Minimal interference with existing scheduling logic
- Clear separation between baseline priorities and dynamic adjustments
- Straightforward implementation
This approach maintains real-time guarantees while enabling dynamic behaviors based on semantic events.