MPU6050 motion study

The question

Can discomfort be turned into a number? And when the board that produces the number dies, what happens to the product?

Glide's hardware came out of this. One Arduino board, asked how much sickness this ride is causing right now, and then asked to tap the wrist before the number crosses the line. The measurement and the buzz pattern set here became the product's hardware. So did the failures.

Why measure first

Motion sickness gets discussed as "uncomfortable", which means no one can check a claim that it improved. A way to measure had to come first.

MSDV was chosen after comparing three ways of measuring sickness (MSDV, MISC, FMS). It is rooted in an international standard, ISO 2631-1, so the work can speak the same units as everyone else's.

Measuring changes nothing on its own. The number has to reach the body.

How

• Two sensors – one MPU6050 on the chassis, one on the head. Sickness comes not from how the car moves but from the difference between the two.
• 50 Hz, calibrated on 200 samples – 200 samples at rest set the baseline, gravity is subtracted, and MSDV is integrated at 50 Hz (design value).
• The buzz – 225 ms on, 100 ms off, 225 ms on, chosen on real rides. One long buzz startles; two short ones don't read as a warning.
• Left and right – the motors are split, so a difference in strength says which way the lean is coming from before it arrives.

What worked and what did not

Worked. After the resting calibration, even a shake by hand showed in the MSDV curve, and the buzz could be sent about two seconds before the threshold. Those two seconds are where Glide's 2–7 second warning began (design value).

Failed. The board's two MPU6050s would not appear on the I2C bus together. Days of chasing address conflicts and wiring never got both read at once, and live measurement stopped there.

The sampling rates disagreed too. GPS updates at 1 Hz, the IMU at 50 Hz. Rather than force them into sync, the roles were split: GPS owns when to warn, the IMU owns how strongly.

So there is a second path. The same formula was rebuilt on the iPhone with CoreMotion, and mock sensor data reproduces the same screens with no board at all. On the day the sensors died, that path kept the demo alive.

The rules that stayed

Choose the unit first. A standard metric can be implemented the same way in several places. In Glide the sensor board, the web console and the iOS app all use one MSDV formula, so what the board measures and what the app shows read in the same language.

Build the demo for the worst conditions. Without a fallback, one piece of hardware decides the presentation.

A failed wire becomes product structure. The I2C failure is why the board and the app still do not talk directly; they go through the web.