basic refactor

README.md

@@ -1,3 +1,124 @@
-Experiment files for the RTIS ros_rt executor. Clone with submodules on, or add the executor to the src folder.
+# Dynamic Priority Scheduling for ROS-EDF Executor
 
-Run `ros2 run casestudy casestudy_example` then run the `analysis/analysis.ipynb` notebook.
+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.