PeerDrive

Demo

About

### **What is PeerDrive?** **PeerDrive is a decentralized, privacy-first vehicle network that lets nearby cars coordinate in real time to prevent traffic and improve safety.** Each car becomes an intelligent node that maintains a precise, local map of nearby vehicles and cooperatively chooses actions—like easing speed to dissolve traffic waves or clearing a lane for an ambulance—without relying on a central server. ### **The problem it solves** - **Reactive systems fail drivers**: Traditional apps learn about congestion after it forms, and centralized networks can be slow or unavailable when it matters most. - **No coordination between vehicles**: Without direct cooperation, small disturbances amplify into stop-and-go waves and delayed emergency response. ### **How PeerDrive works (conceptually)** - **Two-layer communication**: Uses the internet for rich, full-state awareness and a resilient, low-bandwidth radio layer for critical alerts when connectivity is poor. - **Local, bounded awareness**: Each node tracks only its immediate vicinity (roughly hundreds of meters to a couple kilometers), enabling fast, relevant decisions. - **Deterministic “strategy engine”**: With similar local inputs, nearby cars independently compute aligned recommendations, producing coordinated behavior without central control. ### **What drivers experience** - **Calm, actionable guidance**: Simple prompts like “Maintain 65 km/h for smoother flow” or “Prepare to merge left—emergency vehicle approaching.” - **Live neighborhood view**: A clean visual of nearby vehicles and key events (e.g., hard braking ahead, hazard zones). - **Always-on safety**: Critical alerts continue to propagate even if phones lose internet, enhancing trust during edge cases. ### **Core capabilities** - **Traffic wave dissipation**: Detects emerging stop-and-go patterns and recommends small speed adjustments to prevent shockwaves from propagating. - **Emergency passage**: Vehicles receive authenticated emergency signals and coordinate subtle lane shifts to create a “green corridor.” - **Hazard validation and alerting**: Verifies and relays important events (accidents, debris, ice) to give drivers earlier, safer reactions. - **Privacy by design**: Vehicles are recognized by cryptographic identities rather than personal identifiers; only minimal, necessary data is shared. ### **Who benefits** - **Everyday drivers**: Fewer abrupt stops, smoother commutes, earlier warnings. - **Emergency services**: Faster, safer passage through coordinated lane clearing. - **Fleets and logistics**: Reduced delays, better route reliability, safer driving. - **Cities**: Insights into flow and safety dynamics without compromising individual privacy. ### **What success looks like** - **Safety**: Fewer collisions, higher time-to-collision margins, gentler braking. - **Efficiency**: Lower travel-time variance, faster emergency passage, smoother flow. - **Resilience**: Critical signals continue during outages; the network degrades gracefully, not catastrophically. ### **Why it’s different** - **Proactive, not reactive**: Acts before waves form, not after congestion is obvious. - **Decentralized coordination**: Eliminates single points of failure and control. - **Bounded, local intelligence**: Focuses on the immediate environment where decisions matter most. ### **Illustrative scenarios** - **Five-vehicle sudden stop**: With cooperative alerts, following cars brake earlier and more gently—avoiding chain collisions. - **Ambulance approach**: Nearby vehicles get timely signals and smoothly make space; the corridor emerges organically from consistent local choices. ### **Near-term roadmap (at a glance)** - Simulation and algorithm refinement → minimal viable pilot with paired vehicles → city-scale trials with early adopters and fleets → broader deployment. - Built a clear, non-technical description focused on purpose, user value, behavior, and impact. - Avoided implementation details to keep this distinct from the upcoming “How it’s made.”

How it's made

### **How it’s made** - **Core language and architecture** - **Go** monorepo with clear module boundaries: - `cmd/peerdrive` (CLI) and `cmd/peerdrive-gui` (desktop UI entrypoints) - `pkg/strategy/` (simulation engine, scenarios, analysis/metrics) - `pkg/models/` (shared state like `NetworkState`, `VehicleState`) - `pkg/sensor/` (parsers and `mock.go` for synthetic data) - `pkg/network/` (manager, rewards scaffolding) - `pkg/hardware/crypto.go` (crypto/identity primitives) - `ui/` (desktop UI, including `widgets/roadmap.go`) - Go’s goroutines and channels orchestrate the simulation loop, event propagation, and UI updates without a heavyweight runtime. - **Strategy engine (simulation)** - Deterministic tick loop (~50 Hz) advances vehicle kinematics and scenario logic. - Scenarios are started and controlled via `strategy.NewEngine(...)`, `StartScenario(...)`, `IsRunning()`, and `StopScenario()`. - Two canonical scenarios implemented in `pkg/strategy`: - **5‑vehicle sudden stop** (baseline vs V2V-enabled) - **Emergency vehicle priority** (lane-making, passage time) - Metrics computed every tick (TTC, spacing error, peak decel, collision flags, V2V response) and exported as JSON/CSV for analysis. - **State and data model** - `pkg/models/state.go` defines `NetworkState` (peers, alerts, recommendations) and per-vehicle state (position, velocity, acceleration, lane). - The engine treats comms latency as configurable parameters to compare “no comms” vs “V2V” behaviors. - **Sensors and inputs** - `pkg/sensor/mock.go` generates repeatable sensor streams for deterministic tests. - `pkg/sensor/parser.go` defines a thin interface layer so real inputs (phone GPS/IMU or hardware) can replace mocks without touching the engine. - **Networking** - Current simulator runs locally; the **intended** production stack (documented in `docs/Readme.md`) uses a hybrid mesh: - Primary: internet P2P (libp2p) for full-state sync. - Fallback: LoRa for tiny, critical alerts with millisecond propagation. - `pkg/network/manager.go` and `rewards.go` outline the coordination and incentive hooks the engine will call into once live networking is enabled. - **Crypto/identity** - `pkg/hardware/crypto.go` encapsulates cryptographic key handling to represent vehicles as keys (not license plates), enabling authenticated alerts without personal IDs. - **Desktop UI and visualization** - `cmd/peerdrive-gui` launches a desktop app that embeds a right‑panel “road map” widget (`ui/widgets/roadmap.go`). - The widget renders a fixed 2×2 world with three vertical and two horizontal roads (0.4‑unit lanes), maintains a square aspect ratio, and exposes coordinate transforms: - `GetWorldBounds()`, `worldToPixel(x,y)`, `pixelToWorld(x,y)` - Vehicles and events from the engine are drawn over a dark‑gray road grid on a green background with dotted lane dividers. - **Examples and automation** - `examples/demo_scenarios.go` runs both scenarios end-to-end and writes timestamped results. - `examples/compare/` and `examples/compare_scenarios.go` are used to baseline “No Comm” vs “V2V” configurations under identical seeds. - **Build and run** - GUI: `go run cmd/peerdrive-gui/main.go` - CLI demos: `cd examples && go run demo_scenarios.go` - Outputs: realtime console summaries plus JSON/CSV files for post‑hoc analysis. - **Hardware track (prototyping path)** - Documented in `docs/Hardware.md`: a cost‑optimized “Sentinel Unit” built around **ESP32‑S3** + **LLCC68** LoRa transceiver, USB‑C power/data, and external GPS/IMU when needed. - Design-for-manufacture tips: 2‑layer FR‑4, top‑side assembly, 0805/1206 passives, simple jig for firmware flashing/self‑test. - Pragmatic radio choice: **LLCC68** (pin‑compatible with SX1262) delivers ~1–2 km LoS at lower cost. - Certification planning (FCC/CE) and staged manufacturing (proto → 100–500 pre‑prod → mass production) are laid out with BOM targets. - **What was hacky and worth noting** - A “dumb modem” approach: make the LoRa dongle act as a USB‑to‑radio bridge; let the phone/app handle all the heavy logic. This slashes firmware complexity and accelerates iteration. - Deterministic mocks: the sensor/network layers are seeded so scenario runs are bit‑for‑bit comparable, which makes regression spotting trivial. - Fixed world coordinates in the UI widget allow pixel‑perfect rendering and simple math for converting engine outputs to visuals without a full GIS stack. - **Why these technologies** - **Go**: fast binaries, cross‑platform, simple concurrency model, great for both simulation and desktop utilities. - **Hybrid comms (planned)**: libp2p for secure peer discovery + LoRa for outage‑proof safety signals. - **Minimal UI surface**: a custom widget beats map SDK complexity for scenario visualization and keeps the dependency tree thin. - **Partner/adjacent tech and impact** - libp2p (planned): secure channels, NAT traversal, peer discovery for the internet layer. - LoRa (LLCC68): long‑range, low‑bitrate alerts that remain operational during cellular outages. - u‑blox GNSS + phone IMU (planned): high‑frequency kinematics for the strategy engine. - **What’s next** - Wire the engine to a live P2P layer, feed real sensor streams, and validate end‑to‑end emergency alert propagation with two prototype dongles and two phones. - Expand scenarios (merge assist, intersection coordination) and add packet‑loss/congestion models in `pkg/strategy`. - Focused on concrete implementation: code layout, APIs, data flow, concurrency, metrics, UI, hardware approach, and hacky shortcuts—distinct from the high‑level “what/why” description.