pyroboreplay 0.2.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- pyroboreplay-0.2.0/.gitignore +34 -0
- pyroboreplay-0.2.0/CLAUDE.md +287 -0
- pyroboreplay-0.2.0/Cargo.lock +1493 -0
- pyroboreplay-0.2.0/Cargo.toml +29 -0
- pyroboreplay-0.2.0/IMPLEMENTATION_STATUS.md +350 -0
- pyroboreplay-0.2.0/PKG-INFO +275 -0
- pyroboreplay-0.2.0/README.md +248 -0
- pyroboreplay-0.2.0/ROADMAP.md +432 -0
- pyroboreplay-0.2.0/docs/API.md +285 -0
- pyroboreplay-0.2.0/docs/ARCHITECTURE.md +406 -0
- pyroboreplay-0.2.0/docs/CAMERA_EXPORT.md +338 -0
- pyroboreplay-0.2.0/docs/IMU_VISUALIZATION.md +344 -0
- pyroboreplay-0.2.0/docs/KEYBOARD_SHORTCUTS.md +266 -0
- pyroboreplay-0.2.0/docs/LIDAR_VISUALIZATION.md +261 -0
- pyroboreplay-0.2.0/docs/QUICKSTART.md +233 -0
- pyroboreplay-0.2.0/docs/SENSOR_METADATA.md +354 -0
- pyroboreplay-0.2.0/examples/camera_export_demo.rs +101 -0
- pyroboreplay-0.2.0/examples/generate_warehouse_mission.rs +258 -0
- pyroboreplay-0.2.0/examples/imu_visualization_demo.rs +181 -0
- pyroboreplay-0.2.0/examples/keyboard_shortcuts_demo.rs +91 -0
- pyroboreplay-0.2.0/examples/lidar_visualization_demo.rs +166 -0
- pyroboreplay-0.2.0/examples/sensor_metadata_demo.rs +163 -0
- pyroboreplay-0.2.0/examples/test_python_api.py +137 -0
- pyroboreplay-0.2.0/pyproject.toml +46 -0
- pyroboreplay-0.2.0/src/adapters/mod.rs +19 -0
- pyroboreplay-0.2.0/src/adapters/ros2.rs +303 -0
- pyroboreplay-0.2.0/src/cli/args.rs +78 -0
- pyroboreplay-0.2.0/src/cli/camera_export.rs +698 -0
- pyroboreplay-0.2.0/src/cli/imu_viz.rs +475 -0
- pyroboreplay-0.2.0/src/cli/json_output.rs +245 -0
- pyroboreplay-0.2.0/src/cli/keyboard.rs +489 -0
- pyroboreplay-0.2.0/src/cli/lidar_viz.rs +253 -0
- pyroboreplay-0.2.0/src/cli/mod.rs +168 -0
- pyroboreplay-0.2.0/src/cli/replay_ui.rs +331 -0
- pyroboreplay-0.2.0/src/cli/sensor_stats.rs +412 -0
- pyroboreplay-0.2.0/src/core/event.rs +347 -0
- pyroboreplay-0.2.0/src/core/mod.rs +5 -0
- pyroboreplay-0.2.0/src/core/timeline.rs +413 -0
- pyroboreplay-0.2.0/src/lib.rs +201 -0
- pyroboreplay-0.2.0/src/main.rs +8 -0
- pyroboreplay-0.2.0/tests/integration_tests.rs +327 -0
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Rust
|
|
2
|
+
/target/
|
|
3
|
+
**/*.rs.bk
|
|
4
|
+
*.pdb
|
|
5
|
+
Cargo.lock
|
|
6
|
+
|
|
7
|
+
# Python
|
|
8
|
+
__pycache__/
|
|
9
|
+
*.py[cod]
|
|
10
|
+
*$py.class
|
|
11
|
+
*.so
|
|
12
|
+
.Python
|
|
13
|
+
env/
|
|
14
|
+
venv/
|
|
15
|
+
ENV/
|
|
16
|
+
*.egg-info/
|
|
17
|
+
dist/
|
|
18
|
+
build/
|
|
19
|
+
|
|
20
|
+
# IDE
|
|
21
|
+
.vscode/
|
|
22
|
+
.idea/
|
|
23
|
+
*.swp
|
|
24
|
+
*.swo
|
|
25
|
+
*~
|
|
26
|
+
.DS_Store
|
|
27
|
+
|
|
28
|
+
# Project-specific
|
|
29
|
+
*.bag
|
|
30
|
+
*.db3
|
|
31
|
+
.env
|
|
32
|
+
.env.local
|
|
33
|
+
missions/
|
|
34
|
+
tmp/
|
|
@@ -0,0 +1,287 @@
|
|
|
1
|
+
# PyRoboReplay: Mission Debugging & Causal Analysis Platform
|
|
2
|
+
|
|
3
|
+
## Product Vision
|
|
4
|
+
|
|
5
|
+
**PyRoboReplay** is an **AI-agent-first debugging engine** for autonomous robot systems. It reconstructs mission history, replays individual sensor streams, and outputs structured analysis that autonomous agents (Claude Code, Cursor, Codex, etc.) can interpret to understand robot behavior and diagnose failures.
|
|
6
|
+
|
|
7
|
+
Where Foxglove Studio shows "what happened," PyRoboReplay answers "why did it happen?" in a way that **both humans and AI agents can understand**.
|
|
8
|
+
|
|
9
|
+
The platform is:
|
|
10
|
+
- **AI-Agent-Native**: Structured JSON/text output, scriptable CLI, designed for agent integration
|
|
11
|
+
- **CLI-First**: Terminal-native, no GUI dependencies, scriptable pipelines
|
|
12
|
+
- **Sensor-native**: Replay lidar, camera, IMU, odometry, costmaps individually or holistically
|
|
13
|
+
- **Causal**: Track event relationships, not isolated datapoints
|
|
14
|
+
- **Forensic**: Immutable audit trails, deterministic replay, compliance-ready
|
|
15
|
+
- **Diagnostic**: Probabilistic root-cause analysis, cross-mission pattern learning
|
|
16
|
+
- **Agnostic**: Works with ROS 2, Gazebo, Isaac Sim, digital twins, custom telemetry
|
|
17
|
+
|
|
18
|
+
### Why It Matters
|
|
19
|
+
|
|
20
|
+
Robotics teams spend **2-16 hours debugging a single mission failure**—context-switching between rosbags, logs, dashboards, and maps. They manually reconstruct causality ("did obstacle at t=1000 cause stop at t=1050?"). They debug identical bugs repeatedly because failures aren't correlated across missions.
|
|
21
|
+
|
|
22
|
+
PyRoboReplay solves this: unified mission history, causal event graph, automated diagnosis, cross-mission learning.
|
|
23
|
+
|
|
24
|
+
### Elevator Pitch
|
|
25
|
+
|
|
26
|
+
For warehouse operators, drone companies, and robotics researchers debugging mission failures, PyRoboReplay is the analysis platform that transforms fragmented sensor data into actionable diagnoses. Unlike Foxglove (viewer-only) or ROS tools (passive), PyRoboReplay answers: "Why did the robot fail?" and "How do we prevent it?"
|
|
27
|
+
|
|
28
|
+
### AI-Agent Integration
|
|
29
|
+
|
|
30
|
+
PyRoboReplay is designed as a **tool for autonomous AI agents**. It outputs structured analysis that agents can interpret:
|
|
31
|
+
- **Structured JSON**: Mission analysis, event timelines, causal relationships
|
|
32
|
+
- **Scriptable CLI**: Every command has a machine-readable output format
|
|
33
|
+
- **Human-Readable Reports**: Easy for agents to parse and present to humans
|
|
34
|
+
- **Integration-Ready**: Built for Claude Code, Cursor, Codex, and custom agent frameworks
|
|
35
|
+
|
|
36
|
+
Example agent workflow:
|
|
37
|
+
```
|
|
38
|
+
Agent: "Why did the robot stop at t=1050?"
|
|
39
|
+
→ PyRoboReplay: analyzes mission, outputs JSON with causal chain
|
|
40
|
+
→ Agent: Interprets JSON, finds root cause, suggests fix
|
|
41
|
+
→ Agent: Reports to human in natural language
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## The Problem We Solve
|
|
45
|
+
|
|
46
|
+
Current robotics tooling excels at answering:
|
|
47
|
+
- Where is the robot now?
|
|
48
|
+
- What does the map look like now?
|
|
49
|
+
- What is the robot currently seeing?
|
|
50
|
+
|
|
51
|
+
But struggles with:
|
|
52
|
+
- Why was this area never mapped?
|
|
53
|
+
- Why did one robot repeatedly fail while others succeeded?
|
|
54
|
+
- When did an obstacle first appear?
|
|
55
|
+
- Which decision caused a coverage gap?
|
|
56
|
+
- Why did the swarm split into inefficient clusters?
|
|
57
|
+
- How did exploration strategy evolve over time?
|
|
58
|
+
|
|
59
|
+
Engineers currently investigate through fragmented tools (ROS bags, logs, sensor recordings, dashboards, manual reconstruction)—slow and hard to scale.
|
|
60
|
+
|
|
61
|
+
## Core Architecture
|
|
62
|
+
|
|
63
|
+
### Universal Event Model
|
|
64
|
+
|
|
65
|
+
All mission history is normalized to core event types, enabling sensor-level and holistic replay:
|
|
66
|
+
|
|
67
|
+
```rust
|
|
68
|
+
enum MissionEvent {
|
|
69
|
+
// Sensor streams (individually replayable)
|
|
70
|
+
LidarScan { robot_id, timestamp, frame_id, ranges, intensities },
|
|
71
|
+
CameraFrame { robot_id, timestamp, sensor_id, image_data, metadata },
|
|
72
|
+
IMUData { robot_id, timestamp, accel, gyro, magnetometer },
|
|
73
|
+
OdometryUpdate { robot_id, timestamp, pose, velocity, covariance },
|
|
74
|
+
|
|
75
|
+
// Processed/fused state
|
|
76
|
+
RobotPose { robot_id, timestamp, x, y, z, orientation, confidence },
|
|
77
|
+
Costmap { robot_id, timestamp, resolution, origin, grid_data },
|
|
78
|
+
|
|
79
|
+
// Navigation & coordination
|
|
80
|
+
NavigationDecision { robot_id, timestamp, decision_type, path, rationale },
|
|
81
|
+
ObstacleDetected { robot_id, timestamp, location, type, confidence },
|
|
82
|
+
|
|
83
|
+
// Communication & fleet
|
|
84
|
+
CommunicationEvent { timestamp, from, to, event_type, data },
|
|
85
|
+
CoordinationEvent { timestamp, robots_involved, event_type },
|
|
86
|
+
|
|
87
|
+
// Environmental context
|
|
88
|
+
EnvironmentalChange { timestamp, location, change_type, description },
|
|
89
|
+
MissionLifecycle { timestamp, event_type, mission_id },
|
|
90
|
+
|
|
91
|
+
// Causal relationships (v0.5+)
|
|
92
|
+
CausalLink { timestamp, source_event, target_event, relationship_type, confidence },
|
|
93
|
+
}
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
**Key feature**: Each sensor event is independently replayable (e.g., play just lidar over time) or holistically (play full mission with all sensors synchronized).
|
|
97
|
+
|
|
98
|
+
### Input Adapters (Pluggable)
|
|
99
|
+
|
|
100
|
+
Not locked into ROS 2. Adapters normalize external data to universal event model:
|
|
101
|
+
|
|
102
|
+
- **v0.1**: ROS 2 bag reader (most students start here)
|
|
103
|
+
- **v0.2**: Gazebo event stream
|
|
104
|
+
- **v0.3**: Isaac Sim exporter
|
|
105
|
+
- **Future**: Digital twin APIs, custom JSON/CSV, telemetry streams
|
|
106
|
+
|
|
107
|
+
### Timeline Engine (Rust Core)
|
|
108
|
+
|
|
109
|
+
- Event storage and indexing
|
|
110
|
+
- Temporal queries (jump to events, range queries)
|
|
111
|
+
- Spatial correlation (integrates PyTerrainMap context)
|
|
112
|
+
- Event causality tracking
|
|
113
|
+
- Storage backend abstraction (in-memory, PostgreSQL, BigQuery, S3)
|
|
114
|
+
|
|
115
|
+
### Python API
|
|
116
|
+
|
|
117
|
+
Simple for students, powerful for production:
|
|
118
|
+
|
|
119
|
+
```python
|
|
120
|
+
from pyroboreplay import Mission
|
|
121
|
+
|
|
122
|
+
# Student: 30-second replay
|
|
123
|
+
mission = Mission.from_ros_bag("exploration_v1.bag")
|
|
124
|
+
mission.play() # CLI timeline scrubber
|
|
125
|
+
|
|
126
|
+
# Production: Advanced analysis
|
|
127
|
+
mission = Mission.from_events(event_stream, backend="postgresql")
|
|
128
|
+
mission.spatial_context(pyterrainmap_graph)
|
|
129
|
+
mission.find_coverage_gaps()
|
|
130
|
+
mission.root_cause_analysis(failure_timestamp)
|
|
131
|
+
mission.compare_with(other_mission)
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
### PyTerrainMap & StatGuardian Integration
|
|
135
|
+
|
|
136
|
+
PyRoboReplay embeds two key dependencies for spatial context and quality intelligence:
|
|
137
|
+
|
|
138
|
+
**PyTerrainMap** (spatial + temporal layer):
|
|
139
|
+
- Owns: 3D reconstruction, real-time SLAM, traversability analysis, spatial knowledge graphs
|
|
140
|
+
- **Temporal normalization** (5D: x,y,z,time,quality): Already implemented in PyTerrainMap
|
|
141
|
+
- PyRoboReplay uses:
|
|
142
|
+
- Spatial context for causal analysis, coverage evolution, obstacle correlation
|
|
143
|
+
- Temporal normalization for handling out-of-order events (critical for robot fleets)
|
|
144
|
+
- Advantage: Don't rebuild temporal handling; leverage PyTerrainMap's proven implementation
|
|
145
|
+
- Handles clock skew, multi-robot time alignment automatically
|
|
146
|
+
|
|
147
|
+
**StatGuardian** (quality layer):
|
|
148
|
+
- Owns: Data quality contracts, drift detection, anomaly detection
|
|
149
|
+
- PyRoboReplay uses: High-accuracy anomaly flagging across all sensor streams, root-cause confidence scoring
|
|
150
|
+
- Benefit: <2% false positive anomaly detection vs ~5% for rule-based detection
|
|
151
|
+
|
|
152
|
+
This maintains architectural boundaries and maximizes code reuse:
|
|
153
|
+
- PyTerrainMap handles spatial reconstruction + temporal normalization
|
|
154
|
+
- StatGuardian handles data quality/contracts
|
|
155
|
+
- PyRoboReplay orchestrates replay + causality + diagnosis
|
|
156
|
+
|
|
157
|
+
## Core Principles
|
|
158
|
+
|
|
159
|
+
### Principle 1: Input-Agnostic
|
|
160
|
+
Does not lock into ROS 2 alone. Adapter pattern allows seamless integration with Gazebo, Isaac Sim, digital twins, custom formats. Universal event model ensures timeline engine remains independent.
|
|
161
|
+
|
|
162
|
+
### Principle 2: Mapping-Independent
|
|
163
|
+
Does not generate maps. Consumes maps from PyTerrainMap, SLAM systems, GIS platforms. Replay layer remains independent of how spatial data was created.
|
|
164
|
+
|
|
165
|
+
### Principle 3: Explainability First
|
|
166
|
+
Goal is understanding, not just visualization. Every replay event answers: What happened? Why did it happen? What happened next?
|
|
167
|
+
|
|
168
|
+
### Principle 4: Simple to Start, Infinite Depth
|
|
169
|
+
- **Day 1 student**: `pyroboreplay replay mission.bag` → timeline in 30 seconds
|
|
170
|
+
- **Production operator**: Distributed event store, spatial correlation, multi-mission federation, real-time streaming, mission-critical SLAs
|
|
171
|
+
|
|
172
|
+
## Core Features (Roadmap Order) - CLI-First, Aligned to Market Gaps
|
|
173
|
+
|
|
174
|
+
### v0.1: Sensor Replay Foundation + ROS 2 Ingestion ✅ DONE
|
|
175
|
+
**Gap solved**: Data fragmentation (40% of debugging time)
|
|
176
|
+
- ✅ Parse ROS 2 bag files → universal event model
|
|
177
|
+
- ✅ Individual sensor stream replay (lidar, camera, IMU, odometry)
|
|
178
|
+
- ✅ Holistic mission replay (all sensors synchronized)
|
|
179
|
+
- ✅ In-memory timeline + temporal queries
|
|
180
|
+
- ✅ CLI: play/pause/step forward/backward, jump to event
|
|
181
|
+
- ✅ Python API for programmatic access
|
|
182
|
+
|
|
183
|
+
### v0.2: Enhanced CLI + Camera Browser Export
|
|
184
|
+
**Gap solved**: Complete sensor replay in CLI; camera visualization via browser
|
|
185
|
+
- Enhanced CLI with multi-panel views (sensor stats, metadata, real-time graphs)
|
|
186
|
+
- Terminal-based lidar visualization (ASCII 2D polar projection)
|
|
187
|
+
- Terminal-based IMU visualization (graph rendering in terminal)
|
|
188
|
+
- Terminal-based odometry display (pose + velocity vectors)
|
|
189
|
+
- **Camera frame export to HTML**: `pyroboreplay replay mission.bag --export-camera camera.html`
|
|
190
|
+
- Generates standalone HTML file with embedded camera frames
|
|
191
|
+
- Opens in any browser for playback (no server needed)
|
|
192
|
+
- Frame-by-frame navigation, play/pause/speed controls
|
|
193
|
+
- Zero external dependencies
|
|
194
|
+
- Event filtering and search via CLI
|
|
195
|
+
|
|
196
|
+
### v0.3: Causal Analysis Engine (NEW)
|
|
197
|
+
**Gap solved**: Causality invisible (30% of debugging time)
|
|
198
|
+
- Build event dependency graph
|
|
199
|
+
- Link obstacles → navigation decisions → stops
|
|
200
|
+
- Causal queries: "which events led to failure at t=5000?"
|
|
201
|
+
- Temporal correlation window (e.g., events within 2s)
|
|
202
|
+
- Visualization: causal flowcharts
|
|
203
|
+
|
|
204
|
+
### v0.4: Cross-Mission Pattern Learning
|
|
205
|
+
**Gap solved**: Repeated failures (50% of debug effort)
|
|
206
|
+
- Compare missions side-by-side (A vs B)
|
|
207
|
+
- Identify similar failure patterns
|
|
208
|
+
- Anomaly detection (this mission's failure unusual for this robot?)
|
|
209
|
+
- Recommendation engine (if similar failure before, apply previous fix)
|
|
210
|
+
|
|
211
|
+
### v0.5: Root-Cause Diagnosis (NEW)
|
|
212
|
+
**Gap solved**: Manual hypothesis generation
|
|
213
|
+
- Probabilistic diagnosis: "Obstacle detected → navigation deadlock → battery drain"
|
|
214
|
+
- Confidence scores for each hypothesis
|
|
215
|
+
- Counterfactual reasoning: "if obstacle wasn't there, would mission succeed?"
|
|
216
|
+
- Actionable recommendations
|
|
217
|
+
|
|
218
|
+
### v1.0: Production Scale + Forensic Features
|
|
219
|
+
**Gap solved**: Compliance & determinism requirements
|
|
220
|
+
- Pluggable storage backends (PostgreSQL, BigQuery, S3)
|
|
221
|
+
- Streaming real-time ingestion (warehouse ops)
|
|
222
|
+
- Immutable audit trails with cryptographic signatures
|
|
223
|
+
- Deterministic, bit-perfect replay (defense/aerospace)
|
|
224
|
+
- Mission-critical failover + redundancy
|
|
225
|
+
|
|
226
|
+
### v1.1: Advanced Forensics & Real-Time Fusion
|
|
227
|
+
**Gap solved**: Regulatory compliance + operational awareness
|
|
228
|
+
- Real-time + historical fusion (live fleet + past missions)
|
|
229
|
+
- Compliance reporting (audit-ready logs, chain-of-custody)
|
|
230
|
+
- Forensic analysis for accidents/incidents
|
|
231
|
+
- Integration with compliance frameworks (ISO 3691-4, etc.)
|
|
232
|
+
|
|
233
|
+
## Ideal Users
|
|
234
|
+
|
|
235
|
+
- **Robotics researchers**: Analyze swarm experiments
|
|
236
|
+
- **Robotics students**: Debug first exploration missions
|
|
237
|
+
- **Warehouse operators**: Analyze fleet performance
|
|
238
|
+
- **Agriculture companies**: Review inspection coverage
|
|
239
|
+
- **Security companies**: Investigate patrol behavior
|
|
240
|
+
- **Digital twin operators**: Understand environmental evolution
|
|
241
|
+
|
|
242
|
+
## What This Is NOT
|
|
243
|
+
|
|
244
|
+
- Not a SLAM system
|
|
245
|
+
- Not a mapping engine
|
|
246
|
+
- Not a simulator
|
|
247
|
+
- Not a path planner
|
|
248
|
+
- Not a navigation stack
|
|
249
|
+
- Not a terrain database
|
|
250
|
+
|
|
251
|
+
Those systems remain responsible for generating world knowledge. PyRoboReplay helps humans understand how that knowledge was created over time.
|
|
252
|
+
|
|
253
|
+
## Long-Term Vision
|
|
254
|
+
|
|
255
|
+
PyRoboReplay becomes for robotics what:
|
|
256
|
+
- **GitHub** is for source history
|
|
257
|
+
- **Datadog** is for infrastructure observability
|
|
258
|
+
- **Figma version history** is for design evolution
|
|
259
|
+
|
|
260
|
+
A universal observability layer that lets teams rewind, inspect, compare, explain, and learn from autonomous missions across both real and simulated worlds.
|
|
261
|
+
|
|
262
|
+
---
|
|
263
|
+
|
|
264
|
+
## Development Guidelines
|
|
265
|
+
|
|
266
|
+
### Code Quality
|
|
267
|
+
- Type-safe Rust core with comprehensive error handling
|
|
268
|
+
- Python API should feel natural (not a thin wrapper)
|
|
269
|
+
- All public APIs must have docstrings with examples
|
|
270
|
+
- Tests for every adapter and core feature
|
|
271
|
+
|
|
272
|
+
### Architecture Decisions
|
|
273
|
+
- Events are immutable and timestamped
|
|
274
|
+
- Storage backend is pluggable from day one
|
|
275
|
+
- Spatial queries delegate to PyTerrainMap when applicable
|
|
276
|
+
- No hard dependencies on specific robotics frameworks at core level
|
|
277
|
+
|
|
278
|
+
### Performance Expectations
|
|
279
|
+
- Timeline scrubbing: <100ms latency for 1M events
|
|
280
|
+
- Adapter ingestion: Real-time or batch, both supported
|
|
281
|
+
- Spatial queries: <500ms for complex cross-mission analysis
|
|
282
|
+
|
|
283
|
+
### Naming Conventions
|
|
284
|
+
- Rust modules follow Rust conventions (snake_case)
|
|
285
|
+
- Python API follows Python conventions (snake_case)
|
|
286
|
+
- Event types use PascalCase
|
|
287
|
+
- CLI commands use kebab-case
|