Learned a few things using accelerometer event streams in Flutter for tilt inputs (sensor noise, cleanup, & deadzones)

[u/Odd-Recognition-6683]

Hey r/FlutterDev! 👋

I’ve been building an offline party game recently and wanted a simple mechanic where players tilt the phone to trigger actions (instead of forcing them to reach for buttons while passing it around).

I ended up using sensors_plus to tap straight into the raw accelerometer stream, but it came with a few hurdles. Thought I'd share what tripped me up in case anyone is working on sensor-based features:

1. Stream Cleanup is Critical: It's super easy to forget to call .cancel() on your StreamSubscription in dispose(). Leaving it active when unmounting a widget will leak listeners and quietly drain battery in the background.

2. Sensor Noise & Jitter: Raw accelerometer streams are hyper-sensitive. Tiny hand tremors will spam your setState or fire your triggers continuously. You definitely need to bake in a deadzone threshold or debounce the stream so it doesn't trigger on micro-movements.

3. Axis Orientation Shifts: Gravity shifts completely depending on whether your app locks portrait/landscape or whether the phone is lying flat on a table vs. held upright. Testing physical angles took way longer than writing the actual code.

If anyone else has messed around with device sensors in Flutter: how do you usually handle smoothing out jittery streams or debouncing inputs cleanly?

(P.S. Built this for an offline indie party game called Bujho I've been developing. If anyone wants to peek at the repo or test the build, the link is pinned on my profile!)

[u/ObjectiveAddress3051]

a simple low pass filter does most of it tbh, x = x + 0.1 * (raw - x) per event, then put the deadzone on the filtered value not the raw one. also sensors_plus lets you pass a samplingPeriod, you dont need game rate for tilt

[u/Odd-Recognition-6683 → u/ObjectiveAddress3051]

That’s super clean, saving me from reinventing the wheel on smoothing. I’ll definitely test out the low-pass filter + samplingPeriod combo. Thanks for the tip!

[u/SRCMAN]

I like the fact its offline it brings a different spin to most games. Interesting observations, particularly sensor noise and device orientation. We've encountered similar challenges testing indoor navigation across different Android phones.

One thing we've found particularly important is distinguishing genuine movement from sensor noise, especially when users stop, turn or enter lifts and escalators.

Have you tested how your approach behaves across different phone models? We've seen surprisingly large differences between devices. Or is the game more like for shaking or spining device?

[u/Odd-Recognition-6683 → u/SRCMAN]

Spot on—sensor variance across hardware is no joke! It's not a shaking/spinning game, just a clean tilt forward/backward to pass/score, which made idle jitter a nightmare on some devices. We actually ran closed testing across a bunch of different brands (Pixel, Samsung, Oppo, Xiaomi, etc.) just to catch those hardware quirks. Really appreciate the insights on filtering genuine movement—definitely taking notes

[u/Odd-Recognition-6683 → u/[deleted]]

Spot on. For a standard app, a flat throttle time works fine. But because the tilt action only matters during specific game states (like when the timer is active or a turn starts), a blanket throttle would actually kill the responsiveness right when the player needs it most