Gamepad Deadzone

[baqwas]

Are there some references to set a deadzone for a gamepad? Couldn't find anything in the Javadocs.

Our team's TeleOps OpMode started acting up inexplicably without manual interruption - driving straight or spinning at a location. The TeleOperators demonstrated that this random occurrence didn't require any gamepad interaction. The two motions are telltale signs of Mecanum acting on joystick data (in the end-user OpMode) but the drive-train TeleOperator never touched the corresponding joysticks to trigger the effects.

I just read about gamepad deadzone (still learning ;)). Is there anyway to ensure that a deadzone can be custom defined through the SDK?

Simple tests with joysticks indicate continuous readout in the range (-1, 1) when operated in a test OpMode. Perhaps, simply rejecting values around zero (e.g. 10%) should suppress the erratic behaviour (assuming that there are no other undocumented features, i.e. bugs, in the OpMode). Thanks.

Regards.

[Windwoes]

There is not currently a mechanism to apply a user-specified deadzone in the SDK. The SDK does apply a model-specific deadzone on the Driver Station side, with the following values:

public static final float DEADZONE_F310 = 0.06f;
public static final float DEADZONE_OFFICIAL_XBOX_360 = 0.15f;
public static final float DEADZONE_ETPARK = 0.05f;
public static final float DEADZONE_OFFICIAL_PS4 = 0.08f;

The issue with supporting user-specified deadzones is that they are inherently going to be specific to probably not only a certain gamepad model, but also specific unit of that model; so if you were to specify a deadzone in code and then swap the gamepads used by driver 1 and driver 2, now your custom deadzone is wrong.

A better way to support user-specified deadzones would be to add a GUI on the DriverStation to allow saving a gamepad serial-number-specific value. This is something we have considered but has not happened yet. And unfortunately, the Etpark gamepads actually do not contain a unique serial number, meaning this approach would not work for Etpark gamepads.

That all being said, you can still manually clip and re-scale gamepad values in your OpMode using the utility methods in the Range class.

[baqwas]

@Windwoes,

Thanks for your continuing support.

We're using Etpark gamepads. I'll forward your suggestions to our programming team. Using the utility method in the Range class should adequate for our rookie needs.

Kind regards.

[gearsincorg]

Just an additional note.

Many gamepads calibrate the "zero/detent" on their joysticks when the gamepad powers up.

So, if the stick happens to be deflected (by the wrapped cable or surface it's resting on) when it's plugged in, then the gamepad may lock that in is the Zero position. Then, when you free the joystick, it may read that as a deflected stick, and drive/turn the robot when the stick is in the normal "idle" position..

If you see this hapenning, best to unplug and replug the joystick to allow it to recalibrate the zero to the normal detent position.

[baqwas]

Thanks, @gearsincorg.

Last season, our rookie year, the primary programmer complained that he was not happy with the Etpark gamepad and "supplied" his personal (two) Logitech gamepads to the team. He dropped out of the team this season (his senior year) so I never explored the topic with him.

At Screamage FTCNTX in Oct this year, I noticed that the robot at the adjacent table was spinning uncontrollably without operator input. Naturally, this team is a rookie this season!

After our first League Meet this Saturday where we had several bouts of this issue, one of the TeleOperators casually mentioned on the long drive back to school that one (not both) gamepad had "some" issue. We will test the method suggested by @Windwoes today. (I have close to zero experience in using gamepads).

Sorry for the long winded explanation of the issue but I'm trying to get the team to log all issues rather than operate through verbal feedback. But like everything else with the team's work, reconciling methodology is tough when the deadline (exacerbated by supply chain challenges) closes in. I'm glad that so many folks respond to my newbie queries to set me on the right path.

Kind regards.