PeerDrive

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

• 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.