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.
Files changed (41) hide show
  1. pyroboreplay-0.2.0/.gitignore +34 -0
  2. pyroboreplay-0.2.0/CLAUDE.md +287 -0
  3. pyroboreplay-0.2.0/Cargo.lock +1493 -0
  4. pyroboreplay-0.2.0/Cargo.toml +29 -0
  5. pyroboreplay-0.2.0/IMPLEMENTATION_STATUS.md +350 -0
  6. pyroboreplay-0.2.0/PKG-INFO +275 -0
  7. pyroboreplay-0.2.0/README.md +248 -0
  8. pyroboreplay-0.2.0/ROADMAP.md +432 -0
  9. pyroboreplay-0.2.0/docs/API.md +285 -0
  10. pyroboreplay-0.2.0/docs/ARCHITECTURE.md +406 -0
  11. pyroboreplay-0.2.0/docs/CAMERA_EXPORT.md +338 -0
  12. pyroboreplay-0.2.0/docs/IMU_VISUALIZATION.md +344 -0
  13. pyroboreplay-0.2.0/docs/KEYBOARD_SHORTCUTS.md +266 -0
  14. pyroboreplay-0.2.0/docs/LIDAR_VISUALIZATION.md +261 -0
  15. pyroboreplay-0.2.0/docs/QUICKSTART.md +233 -0
  16. pyroboreplay-0.2.0/docs/SENSOR_METADATA.md +354 -0
  17. pyroboreplay-0.2.0/examples/camera_export_demo.rs +101 -0
  18. pyroboreplay-0.2.0/examples/generate_warehouse_mission.rs +258 -0
  19. pyroboreplay-0.2.0/examples/imu_visualization_demo.rs +181 -0
  20. pyroboreplay-0.2.0/examples/keyboard_shortcuts_demo.rs +91 -0
  21. pyroboreplay-0.2.0/examples/lidar_visualization_demo.rs +166 -0
  22. pyroboreplay-0.2.0/examples/sensor_metadata_demo.rs +163 -0
  23. pyroboreplay-0.2.0/examples/test_python_api.py +137 -0
  24. pyroboreplay-0.2.0/pyproject.toml +46 -0
  25. pyroboreplay-0.2.0/src/adapters/mod.rs +19 -0
  26. pyroboreplay-0.2.0/src/adapters/ros2.rs +303 -0
  27. pyroboreplay-0.2.0/src/cli/args.rs +78 -0
  28. pyroboreplay-0.2.0/src/cli/camera_export.rs +698 -0
  29. pyroboreplay-0.2.0/src/cli/imu_viz.rs +475 -0
  30. pyroboreplay-0.2.0/src/cli/json_output.rs +245 -0
  31. pyroboreplay-0.2.0/src/cli/keyboard.rs +489 -0
  32. pyroboreplay-0.2.0/src/cli/lidar_viz.rs +253 -0
  33. pyroboreplay-0.2.0/src/cli/mod.rs +168 -0
  34. pyroboreplay-0.2.0/src/cli/replay_ui.rs +331 -0
  35. pyroboreplay-0.2.0/src/cli/sensor_stats.rs +412 -0
  36. pyroboreplay-0.2.0/src/core/event.rs +347 -0
  37. pyroboreplay-0.2.0/src/core/mod.rs +5 -0
  38. pyroboreplay-0.2.0/src/core/timeline.rs +413 -0
  39. pyroboreplay-0.2.0/src/lib.rs +201 -0
  40. pyroboreplay-0.2.0/src/main.rs +8 -0
  41. 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