At our last competition, we noticed that the thumbsticks on the gamepads we are using have a very significant deadband - roughly a third of the full throw of the thumbstick! This is making slight turns at speed extremely hard to do accurately.
Does anyone have any suggestions for gamepads that do not suffer from this issue?
I know some teams compensate it in code. If you cube the values of your joystick you can get a much more gentle acceleration.
http://i.imgur.com/4dl2Wyx.png
That way even if you have a deadzone to ±0.3 you still have a lot of control over your robot.
As you can see in the graph even at 33% deadzone you still have very fine control of movement.
This was what I was going to suggest. If you use Labview, I have spec sheets and code that I could send to you that could help.
We know about doing this, but we’d still much rather have joysticks where the full range of motion (or close to it) is usable.
What gamepads are you using now?
Don’t know the model off the top of my head - I will check and get back to you.
I would recommend trying the Logitech Gamepad F310 (http://www.bestbuy.com/site/logitech-f310-gaming-pad-blue-black/1260591.p?skuId=1260591). We have used these for years because they have much better joysticks than most of the other gaming controllers.
We’ve always used xBox 360 controllers. Dead-band area is not too bad, but have never used another controller for comparison.
David
These are pretty much the ‘baseline’ of controllers that many teams have used for years. We use them as well. Quality joysticks will give far more range of motion for more controlled response, but there are other drawbacks to those - ease of button access, space and packaging, etc.
We did some rough testing on an Xbox 360 controller from FIRST Choice, and an Xbox One controller by getting each thumbstick to ‘stick’ to one side or the other, and write down the raw value being read by the computer (using the windows gamepad test utility). This range is more of less non-usable since we don’t want the robot moving when the particular axis is not being used.
This rough calculation showed that the Xbox One worst case was between 2.3% and 4% of the overall range, where the Xbox 360 was between 5% and 13% of the overall range. The motor output should be 0 in this range. Since there was fairly significant, we went with the Xbox One and this made a big difference.
Next we determined the range of joystick values which barely start to move the motors, and scale our outputs to be between that value and 1. See the ‘b’ parameter in Ether’s paper here (or the attached VI). Finally the actual sensitivity can be set with the ‘a’ parameter in the same paper. Remember that by default the LabVIEW VIs square your joystick input. So either disable it or account for it when you set the parameter.
One last thing our team did to help with the sensitivity was to add ‘kontrolfreek’ extenders to the Xbox One controller to make the physical stick higher. I’m not sure if this really helped or not, but it seemed to allow us to set the sensitivity higher.
Joystick_Sensitivity.vi (120 KB)
Joystick_Sensitivity.vi (120 KB)
Like mentioned by nickmcski above, we often cube (or even higher power) our controls for finer accuracy. Another thing that really helps, that can be used with or without the power adjustment, is to remove the jump. Normally with the dead band, the first power you can achieve is the deadband value. So, in the case of XBox controllers, where the deadband can be as large as 20%. (Calibrating the joysticks in the Windows control panel can help with this BTW). But if you’re stuck with a 20% deadband the lowest power you can apply is around 21%. You can re-linearize the 80% range you have left so that it maps to 0.0 to 1.0 instead of 0.2 to 1.0. This doesn’t change the fact that you lost 20% of the motion of the stick, but at least you can push it to small values like 0.1 once you hit the active area.
Just use this (Java):
if (Math.abs(joystickAxis) < deadBand) {
joyStickAxis = 0.0;
}
else {
if (joyStickAxis>0.0) {
joyStickAxis = (joyStickAxis - deadBand) / (1.0 - deadBand);
}
else {
joyStickAxis = (joyStickAxis - -deadBand) / (1.0 - deadBand);
}
}
or shorter, but trickier to read:
joystickAxis = Math.abs(joystickAxis) < deadBand ? 0.0 :
(joyStickAxis - Math.signnum(joystickAxis)*deadBand) / (1.0 - deadBand);
This is not actually the case with our joysticks - the value does scale smoothly from 0 to 1, it simply does so over a depressingly small fraction of the joystick’s physical throw.
joystickAxis = Math.abs(joystickAxis) < deadBand ? 0.0 :
(joyStickAxis - Math.signnum(joystickAxis)*deadBand) / (1.0 - deadBand);
For anyone who doesn’t get this, look up “ternary operator.”
We use the xbox controllers. I have a set of the F310 controllers, but our drivers over the last 4 years prefer the layout of the xbox over the F310.
We also use halo controls for driving, so throttle is on the left stick Y axis, and turning is on the right stick X axis.
I suppose that could play into your selection, as the xbox sticks are offset, and the logitech they are on the same elevation, which maybe better if you are driving in a tank mode.
We have to deadband the xbox controllers at .15 to .20 as sometimes they will stick when not actuated, but the full range is usable.
Our drivers also like the inputs squared, but you need to maintain the sign, cubed was too damped.