Skip to content

Gamepad / Joystick Drift — Robot Moves Uncommanded, Deadband Fix

Summary

Uncommanded robot movement during live gamepad control (the robot drifts or creeps when no stick is being touched) is almost always caused by analog stick center slop — the mechanical imprecision at the stick's neutral position produces a small non-zero value that Flair interprets as a slow movement command. The fix is to increase the Deadband setting in Flair's controller axis configuration for each affected axis. Deadband defines a range around the center position that is treated as zero — any input within that range is ignored. A starting value of 5–10% deadband is typical; increase until drift stops. If the problem appeared suddenly on a previously-working controller, the analog stick pot may be worn and the controller should be replaced.

Symptoms

  • Robot slowly drifts or creeps on pan, tilt, or other axes when no gamepad input is given.
  • Move starts before the stick is fully released, or continues briefly after releasing.
  • Live control feels imprecise — robot won't stay still at a position.
  • Problem is worse after the controller has been in use for some time (worn analog potentiometers).
  • Issue appears on one axis only, suggesting a specific stick/pot has worn.

Community Guidance

[RESOLVED] Increase Deadband on the Affected Axis

Community consensus

In Flair's controller axis assignment, each axis has a Deadband parameter. This defines the percentage of the full stick travel range around center that Flair ignores (treats as exactly zero).

How to adjust: 1. Open Flair → Controller panel → Axis Setup. 2. Find the axis that is drifting. 3. Increase the Deadband value for that axis. 4. Test: with the stick at rest, the robot should be completely still. 5. Start with 5–10% deadband. Increase if drift persists.

Note: increasing deadband reduces the effective resolution of the stick (the "dead zone" around center is larger), so find the minimum value that eliminates drift.

confidence_score: 0.93

[RESOLVED] Replace Worn Controllers

Community

Analog stick drift typically worsens over time as the potentiometers inside the stick wear out. If maximum deadband settings still do not eliminate drift, the controller should be replaced. The Logitech F310 is inexpensive enough to keep a spare on hand.

Controllers used in heavy production environments (daily use for months) should be treated as consumables.

confidence_score: 0.90

[INFORMATIONAL] Uncommanded Motion vs. Runaway — Important Distinction

Community — see also CTRL-wireless-controller-driver-runaway.md

Slow drift from analog stick center slop is a nuisance but generally controllable — the robot drifts slowly and can be stopped. This is distinct from a controller runaway, which can occur with wireless controllers or driver conflicts where the robot receives a full-speed command and cannot be stopped via the gamepad. Always use wired controllers to avoid runaways, and always have the e-stop accessible.

confidence_score: 0.95

[OPEN] Erratic Drift on Linux + Flair Bridge — Different Root Cause, Not Deadband (2026-06-18)

Community — 31 6 27072527, Ben Myers, Timothy Heys Cerchio, Chavez.Camera, Simon Wakley — 18-19 June 2026

A separate, unresolved symptom family from the deadband/worn-pot drift documented above — do not conflate the two. On a Linux rig running Flair Bridge, joystick response was erratic and inconsistent: unpredictable lag/delay between input and robot response, sometimes drifting, not reproducible on demand, and not fixed by the usual deadband/HHB-delay tuning.

"I will avoid using the controller for now as we will be shooting with a probelens and very close to the products... Yeah .. I tried 3 different controllers as well .. never had an issue like this."

Things checked and ruled out in this thread: robot delay / position delay / network buffer tuning (values tried, no change), Jerk setting (was 0 on all axes, the Flair 7 default), controller being wired vs wireless (confirmed wired), and camera mount/lens setup (confirmed correctly configured).

Timothy Heys Cerchio: "Those delays are in 'ticks' - fractions of a second... Nowhere near the huge response delay you are seeing here."

Ben Myers: "Yea seems like a bug. It's interesting that the delay isn't consistent either."

Things tried, unconfirmed:

  • Loading a previous job file known to have worked with a controller before — this actually made things worse on a job saved without Flair Bridge configured, since Flair then tried to reset to default and lost connection with the arm/RIC.
  • File → Reset Configuration to restore last-known default settings for the rig — suggested but the operator deferred trying it until after an imminent shoot, so it's unconfirmed.
  • Rolling back to a previous Flair version — planned but not confirmed in this thread.

Simon Wakley: "Get a PC and try Classic ;-) My guess would be a driver issue in Linux. Very strange and disconcerting.."

If you hit this: don't assume it's the same deadband issue as above — HHB deadband/delay tuning does not touch this. Try File → Reset Configuration (or a clean reload of the Flair Bridge profile) before touching job-level settings, and consider testing on Classic/a different OS to isolate whether it's Linux-driver-specific.

confidence_score: 0.55