124 lines
3.5 KiB
Markdown
124 lines
3.5 KiB
Markdown
# 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:
|
|
|
|
```cpp
|
|
int dynamic_priority_boost = 0;
|
|
```
|
|
|
|
Then modify the comparator to consider this value:
|
|
|
|
```cpp
|
|
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:
|
|
|
|
```cpp
|
|
float priority_multiplier = 1.0f;
|
|
```
|
|
|
|
And then in the comparator:
|
|
|
|
```cpp
|
|
// 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:
|
|
1. Clean semantics
|
|
2. Minimal interference with existing scheduling logic
|
|
3. Clear separation between baseline priorities and dynamic adjustments
|
|
4. Straightforward implementation
|
|
|
|
This approach maintains real-time guarantees while enabling dynamic behaviors based on semantic events.
|