Jun 2026 – Current · Product, engineering, design
Closed testing · Windows live
Orbital — Motion Sickness Relief Overlay
Click-through overlay of dots that drift with real vehicle motion, so you can read or work in a moving car. Windows app + Android companion with cross-platform sensor fusion, a GPS/IMU complementary filter, and three phone-to-PC transports.
- C# / .NET 8
- WPF
- Kotlin
- Android
- Sensor fusion
- WebSockets / TLS
- Bluetooth RFCOMM
- Play Billing
- MSIX
Last updated
Context
Car sickness happens when your eyes and inner ear disagree: the vestibular system feels every swell of acceleration while your gaze is locked on a perfectly still page. Orbital fixes the disagreement instead of masking it — a click-through, always-on-top overlay of drifting dots along the screen edges that move in time with the real vehicle, so peripheral vision confirms what the inner ear reports. You keep reading; the edges tell the truth.
Two apps, one motion pipeline: Orbital for Windows (free desktop overlay) and Orbital Phone (Android companion, currently in closed testing on Google Play) that streams its sensors to the laptop or runs standalone.
Live: wroughtery.com/orbital — product page + Windows download

The sensor pipeline
The hard part isn't drawing dots — it's producing a truthful motion signal from consumer IMUs in an arbitrarily mounted phone:
- Gravity estimation with freeze/re-learn — a low-pass gravity vector that freezes during sustained motion (so braking doesn't get absorbed into "down") and re-learns at rest.
- Mount-orientation auto-learning — axis mapping locks only near standstill, so the phone can sit in any pocket or cradle and cues still map to forward/lateral correctly.
- Turn detection as yaw-rate about gravity — mount-independent by construction.
- GPS/IMU complementary filter — raw accelerometers can't hold a sustained braking signal (it re-zeros within a second), so GPS-derived acceleration is blended into the longitudinal channel with jerk-slew limiting, a stop deadband, and a stillness gate. This came out of real subway and car test logs, not simulation.
The same pipeline runs in C# on Windows (Windows.Devices.Sensors for laptops with built-in IMUs) and Kotlin on Android, and a built-in motion simulator injects synthetic IMU/GPS frames into the production code path for scripted QA scenarios.

Three transports, zero accounts
Phone-to-PC streaming is fully local — no cloud, no accounts, no telemetry:
- A hand-rolled WebSocket server (RFC 6455 handshake on a raw
TcpListener) overSslStreamwith a self-signed cert generated and cached on first run. - A parallel Bluetooth RFCOMM path for cable-free use without a shared network.
- A browser-only fallback: any phone opens a QR-pairing URL and streams
DeviceMotionevents over HTTPS — nothing to install.
Desktop engineering
The Windows app is a single self-contained .NET 8 / WPF binary: click-through layered window rendering, global low-level hotkeys, tray integration, auto-start registration, and two packaging paths (Inno Setup installer + MSIX for the Microsoft Store). Android splits sensor capture and overlay rendering into separate foreground services, with a custom SYSTEM_ALERT_WINDOW view and Play Billing subscription gating the Pro tier.

Takeaways
Sensor fusion on consumer hardware is an exercise in distrust: the fused Android sensors actively fight you (linear acceleration re-zeros sustained accel within ~1s), so every cue channel needs an independent reference — gravity for orientation, GPS for sustained acceleration, yaw-about-gravity for turns. The design that survived came from logging real drives and reading the failures, and the simulator that replays those logs through the production pipeline turned out to be the most valuable component in the repo.