Glide

Summary

A motion-sickness relief system for autonomous rides: it warns 2–7 seconds before the car moves, so riders can brace themselves. One sickness metric (MSDV) runs the same way on a sensor board, a web console and an iOS app.

2 → 7s

Warning ahead of the motion

Design value · scaled by speed, retuned on real rides

3

Places the same metric runs

Sensor board · web console · iOS app

8

Alert channels it switches between

Output · five priority levels

Role – problem framing · UX · algorithm · web · iOS · firmware · wearable mock-ups (solo)

Overview

Warning first is the whole product. Glide does not soothe the rider after the car sways. It speaks 2–7 seconds before, so the body gets ready first.

The warning alone is not enough. Riders in an autonomous car don't look ahead. They watch, work and sit facing each other. For someone not looking at a screen, a screen is not a channel. So the system predicts the motion first, then picks the sense the rider can actually perceive at that moment. Those two steps are the whole structure.

The product splits into four layers: L0 route intelligence, L1 cabin control, L2 sensory cues, L3 wearables. L1 needs vehicle-control access, which is the hardest to get organisationally. So the product was split to let L0 and L2, which need no access, stand on their own first.

The web console has its own page – Glide Console

Problem

• Cause – a clash between vision and the vestibular sense. Autonomy adds time not looking ahead, other activities and facing seats. Facing seats measurably increase sickness (MDPI, 2025).
• Scale – research reports 6–10% of autonomous-vehicle riders regularly experiencing moderate to severe sickness (Sivak & Schoettle), and up to a third of Americans getting car-sick (NIH · Mcity).
• The paradox – avoid multitasking and the sickness goes away; so does the whole point of autonomy.

Key decisions

1. 01Speak before the motion, not after it

   Detecting motion and correcting the screen is already being done by several products. The defensible point is not the detection but the warning: given warning, a rider takes an active posture instead of swaying passively.

   →The alert lands 2–7 seconds before the car sways (design value). On a curve the vibration flows top to bottom, so the rider tilts their head into the turn (Active Head Tilt).

2. 02Change the sense, not the amount of information

   Facing backwards or watching a video, a rider won't see an on-screen alert. Too many alerts get ignored, and ignored alerts destroy trust.

   →Rear-facing: all visuals off, vibration and sound instead. Busy with something else: light and vibration instead of text. It speaks only past a threshold, and if a movement repeats within five seconds the screen stays off from the second time and only vibration remains. Eight alert channels, five priority levels (output).

3. 03Let the rider choose between time and comfort

   Whether the fastest or the calmest route is best depends on the moment. It is not a call the system should make.

   →A four-step slider: Rush · Cruise · Glide · Pure Glide. The calmest route took 18% longer (simulation). Every step of intervention carries an undo.

4. 04Trust the ride over the spec

   The first warning times, 1.5 / 2 / 3 seconds, felt too late on real rides. There was no time to brace.

   →Warning times went up to 2 / 3 / 5 / 7 seconds, scaled by speed (design value), with a 40 m minimum warning distance (design value). The design document was changed instead of the experience.

5. 05Put privacy ahead of accuracy

   The sickness metric is integrated on the phone, without a cloud. Raw sensor data then has no reason to leave the device, and data that was never sent is not subject to regulation either.

   →Health-data integration was removed and face video is never stored. The cost was detection accuracy. Regaining it belongs to production, through sensors already built into the car.

›The silence rules, the thirteen steps, the warning-distance formula and the sickness metric

Silence – “silence = trust” became a written principle. On steady straight stretches there are zero alerts. A system that always talks gets switched off.

Thirteen steps – intervention is proportional to severity, from a button that is always present (D0), through a suggestion and acting-then-saying-so, to stopping and setting off again (D12). Every step carries an undo. The recovery protocol is a separate three steps: past a sickness figure of 10 the display dims and the seat reclines (design value, 38°); past 18 the car looks for a safe place to pull over.

Warning distance – max(40 m, speed × warning time × sensitivity).

The sickness metric (MSDV) – acceleration is squared and accumulated over time, then turned into a 0–100 Glide Score, with state boundaries at 4 · 10 · 18 (design values). The sensor board, the web console and the iOS app all use that one formula, so what the board measures and what the app shows read in the same language.

Two scores with one name – the route score is a prediction before the ride; the drive score accumulates during it. Same name, different formula.

Still a proposal – weighting sickness against time as a cost function, and letting the user pick a point on the slider instead of the system picking an optimum, is a design proposal. It is not implemented.

Process

Research

• The metric – three ways of measuring sickness (MSDV, MISC, FMS) were compared, and MSDV, rooted in an international standard (ISO 2631-1), was chosen: a standard metric lets the work speak the same language as everyone else's.
• Competitors – Apple Vehicle Motion Cues, ClearMotion, Bosch, Toyota and Holoride were compared. The conclusion wasn't "nobody does this" but "nobody connects it": none joins measuring, predicting, warning and explaining in one flow. Prior art here is dense, so none of this is called original technology.
• Validation – self-reports alone weren't enough. Four axes were tracked together: physical (IMU-based MSDV), physiological (heart rate, head posture), subjective (MISC, FMS) and behavioural (head-down and hand-to-mouth gestures, detected by CV). An effect only counts when all four axes agree. All four are built, but the sample is too small for statistical significance yet.
• Data – Tmap routes and POIs, OSM/Overpass and Seoul TOPIS are actually wired in.

Design

• Five principles – warning is the golden time · silence = trust · speak only at thresholds · a priority order of senses · never blame the rider ("We've got you").
• Haptics – a 225 ms on, 100 ms off, 225 ms on pattern, tuned on real rides, with a different strength curve per direction. The vibration flows top to bottom on a curve for one reason: to get the head tilting into the turn. Passive sway becomes an active posture.
• Screens – five in-car display states, six Dynamic Island states, three widgets and two live activities, and 50+ alert messages (output).
• What the hardware forces on the UX – an overhead monitor makes riders lift their chin, which can cause sickness rather than relieve it. That screen got the lowest information density of any.

Prototype

Three parts run on one sickness metric. The board measures the real motion, the console watches it and tunes, the app tells the rider. The board and the app are not directly connected; they go through the web.

• Sensor board – an Arduino with two MPU6050s (one for the car, one for the head) and left/right vibration motors, sampling at 50 Hz and calibrating on 200 samples at start.
• Web console – the sickness metric on a map, and an experiment tool for replaying scenarios by hand.
• iOS app – SwiftUI, CoreMotion, AirPods head-motion and haptics. The build passes. It isn't on TestFlight yet: the privacy manifest and permissions are done, and what remains is a paid developer account and signing.

›Sensor board and wearable specs

Board – Arduino, two MPU6050s, a MAX30102 heart-rate sensor, left/right vibration motors. 50 Hz sampling, 200-sample calibration at start. Heart rate is measured on the research board only; the consumer iOS app uses no health data.

In-car display – Waveshare ESP32-S3-Touch-AMOLED-1.32, a 466×466 overhead monitor, LVGL V8.

Wearable mock-ups – a parametric model in OpenSCAD, surfaced in Fusion 360, sliced in Bambu Studio. The earpiece drives a vibration motor against the mastoid bone (21×30×3 mm); how open-ear headphones sit on the ear was studied first. The vision band puts two LRAs at the temples under separate control. The ear-hook curve kept breaking until it was rebuilt as a chain of hull() operations. Looking at how a real product is worn would have been faster than modelling from scratch.

iOS – CMHeadphoneMotionManager reads AirPods head posture, AVAudioEnvironmentNode places the sound in space. TrueDepth video is never stored.

Activity

Research console

The warning and the silence had to be tested before the algorithm existed. So the first thing built was an experiment tool where a person sets the timing and the intensity by hand while the rider sees what looks like an automatic system. That console, where sensors, simulation, audio, haptics and vision are tuned on one screen, has its own page – Glide Console

Results

−78%

Stop-and-go · simulation

−77%

Sickness metric (MSDV) vs the shortest route · simulation

+18%

Extra travel time · simulation

The same stretch was driven with Glide on and off, and the accumulated MSDV curves compared. The tool that ran the comparison is the simulation engine in the research console.

Where a person steps in

• By itself – the sickness figure (MSDV) is measured continuously and spoken before it crosses the line.
• By hand – intervention is proportional to severity: from a light suggestion, through acting and then saying so, to stopping the car, across thirteen steps. Every step carries an undo. The trade between time and comfort is always the passenger's to make.
• Silence is designed too – below the threshold it says nothing. A system that always talks gets switched off.

Reflection

What held up

• One metric, implemented the same way in three places. What the board measured, the curve the console drew and the score the app showed all read in the same language. With three formulas, the first argument would have been about which value to trust.
• Putting the warning at the centre. Detection and mitigation are crowded. Changing the rider's posture through advance warning is the part this product can defend.
• Building the demo for the worst conditions. When the sensors died, the mock path kept the demo alive.

What failed

• I trusted the spec over the body. Warning times of 1.5 / 2 / 3 seconds were fine on paper and late on a real ride. The thing to protect was the experience, not the number.
• I assumed the board and the app would talk directly. The motion sensors never appeared on the I2C bus. The board still goes through the web.
• I read UX inconsistency as a screen problem. It was usually an information-architecture problem. Vehicle settings scattered across several screens became one shared component.
• I thought the consumer ride-hailing app could come first. The direction changed to an SDK for carmakers plus a companion app that works in any car. A consumer app is tied to one region and the SDK isn't, and the operations tool built for experiments was already the screen a customer would use.

What I would test next

• An in-car controlled trial. Every effect number here is simulated. The same stretch has to run A/B in a real vehicle.
• Whether the four axes agree. All four are built. The sample is not there yet.
• The TestFlight release. What remains is a paid developer account and signing.
• Direct Bluetooth and a personalised model. Whether warning times should differ per person is still unknown.