ROS-Dynamic-Executor-Experi.../README.md

160 lines
4 KiB
Markdown
Raw Normal View History

2025-04-13 21:02:39 +02:00
# ROS 2 Dynamic Priority Executor with Performance Monitoring
2025-03-22 19:49:02 -04:00
2025-04-13 21:02:39 +02:00
This repository contains a ROS 2 executor implementation with priority-based and deadline-based scheduling capabilities, including comprehensive performance monitoring.
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## Performance Monitoring Features
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
- High-resolution event tracking for callbacks
- Chain-aware monitoring for multi-callback sequences
- Deadline tracking and violation detection
- Thread-aware monitoring in multi-threaded executors
- Automatic JSON log generation
- Configurable buffer sizes and auto-dumping
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## Quick Start
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
1. Clone the repository:
```bash
git clone --recurse-submodules https://github.com/user/ROS-Dynamic-Executor-Experiments.git
2025-04-01 16:04:19 +02:00
```
2025-04-13 21:02:39 +02:00
2. Build the project:
```bash
colcon build
2025-04-01 16:04:19 +02:00
```
2025-04-13 21:02:39 +02:00
3. Source the workspace:
```bash
source install/setup.bash
```
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## Using the Performance Monitor
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Basic Setup
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
```cpp
#include "priority_executor/priority_executor.hpp"
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
// Create executor with monitoring enabled
auto executor = std::make_shared<priority_executor::TimedExecutor>(options, "my_executor");
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
// Configure monitoring options
executor->setMonitoringOptions(
10000, // Buffer size
5000, // Auto-dump threshold
"performance_logs" // Output directory
);
```
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Monitoring Configuration
- **Buffer Size**: Maximum number of events to hold in memory
- **Auto-dump Threshold**: Number of events that triggers automatic file dump
- **Output Directory**: Where performance logs are saved
### Event Types Tracked
- `CALLBACK_READY`: Callback is ready for execution
- `CALLBACK_START`: Callback execution started
- `CALLBACK_END`: Callback execution completed
- `DEADLINE_MISSED`: A deadline was missed
- `DEADLINE_MET`: A deadline was successfully met
- `CHAIN_START`: Start of a callback chain
- `CHAIN_END`: End of a callback chain
### Performance Data
Each event captures:
- High-resolution timestamps
- Node and callback names
- Chain IDs and positions
- Deadlines and processing times
- Thread IDs (for multi-threaded executors)
- Additional context data
### Output Format
Performance logs are saved as JSON files with the following structure:
```json
[
{
"timestamp": 1234567890,
"type": "callback_start",
"node_name": "example_node",
"callback_name": "timer_callback",
"chain_id": 1,
"is_first_in_chain": true,
"deadline": 1000000,
"processing_time": 500,
"executor_id": 0,
"additional_data": {
"thread_id": 1,
"cpu_affinity": 1
}
}
]
```
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Multi-threaded Monitoring
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
The monitoring system automatically handles multi-threaded executors:
- Tracks per-thread execution
- Records CPU affinity
- Thread-safe event recording
- Maintains event ordering
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Best Practices
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
1. Set appropriate buffer sizes based on your system's memory constraints
2. Enable auto-dumping for long-running systems
3. Use meaningful executor names for better log analysis
4. Monitor deadline compliance in real-time systems
5. Track callback chains for end-to-end latency analysis
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Analyzing Results
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
1. Performance logs are saved in the configured output directory
2. Use the provided Jupyter notebook for analysis:
```bash
jupyter notebook analysis/analysis.ipynb
2025-04-01 16:04:19 +02:00
```
2025-04-13 21:02:39 +02:00
## Advanced Usage
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
### Manual Log Dumping
2025-04-01 16:04:19 +02:00
```cpp
2025-04-13 21:02:39 +02:00
auto& monitor = PerformanceMonitor::getInstance();
monitor.dumpToFile("custom_log_name.json");
2025-04-01 16:04:19 +02:00
```
2025-04-13 21:02:39 +02:00
### Temporary Monitoring Disable
2025-04-01 16:04:19 +02:00
```cpp
2025-04-13 21:02:39 +02:00
executor->enableMonitoring(false);
// ... execute some callbacks ...
executor->enableMonitoring(true);
2025-04-01 16:04:19 +02:00
```
2025-04-13 21:02:39 +02:00
### Custom Event Context
Additional context can be added to events through the `additional_data` field in JSON format.
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## Performance Impact
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
The monitoring system is designed to be lightweight:
- Lock-free recording for most operations
- Efficient event buffering
- Configurable buffer sizes
- Optional auto-dumping
- Minimal overhead during normal operation
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## Contributing
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
Contributions are welcome! Please follow these steps:
1. Fork the repository
2. Create a feature branch
3. Commit your changes
4. Create a pull request
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
## License
2025-04-01 16:04:19 +02:00
2025-04-13 21:02:39 +02:00
Apache License 2.0 - See LICENSE file for details