Trigger Button Potential Bug

[swinterbotix]

Hi,

I'm using the 'joy' package to create a ROS interface for a PS3 or PS4 controller, and I noticed that by default, the L and R buttons on the joystick (maps to index 2 and 5 respectively in the 'axes' array) are set to 0. However, after pressing the R button and letting go, the R value in the 'axes' array stays at 1.0. Same is true for the L button. Would it be possible to just set the default L and R button values in the ROS Joy message to 1.0? I ask since for my application, the R and L values depend on each other, and I have to create a special case in my code to check for the very first press of each of these buttons (as my code assumes that they will always have a value of 1.0 when unpressed).

As an FYI, I'm using the Official PS3 and PS4 Sony controllers with Ubuntu 16.04 and ROS Kinetic though I believe the same issue occurs on Ubuntu 18.04 and ROS Melodic.

[SomeshDaga]

I am seeing this on a wireless xbox360 joystick too. The trigger buttons seem to map to values between -1 and 1, and after pressing the releasing the trigger button(s) once, the axes values remain at 1. Is this intended functionality?

[FHainzl]

I'm experiencing the exact same issue: Before using LR and RT, all values in axes are zero. After the first press axes[2] (LT) and axes[5] (RT) are 1.0 when the buttons are untouched.
This is with an XBOX 360 controller.

[lauralindzey]

I'm seeing the same issue with both an xbox one joystick and a logitech F310, running on Noetic.

The behavior I would have expected is 0.0 corresponds to the axis in a resting position, and 1.0 corresponds to all the way pressed. However, a quick look at the driver code makes it look like this oddness is thanks to the actual hardware driver, rather than the ROS node, and fixing it would require special casing two event numbers.

[JWhitleyWork]

This is sort-of a "known bug" but it's more complicated than it looks. The problem is that "triggers" are considered "axes" for the purpose of defining their range of values, in this case: 1.0 to -1.0. However, since "triggers" don't have a clearly-defined (read "default" or "detented") center point, the only way to represent the full range-of-motion of a "trigger" as an "axis" is to have one end of the range-of-motion be 1.0 and the other end be -1.0 with 0.0 representing the "middle", which, again, is not clearly defined on the hardware itself. Since we must treat all "axes" the same, the default value of 0.0 was chosen as a "safe" value. However, for a trigger, this is obviously not a sane value. This leaves us with a few options:

1. Specify a different default value of all axes.
   • This is problematic due to other assumptions made in the existing joy node and that it doesn't make sense for other types of controls which are handled as "axes" (e.g. analog sticks/D-pads).
2. Split triggers into their own group of controls.
   • This is problematic due to other assumptions made in the existing joy node and the requirement that the joy_msgs also be changed, which are very ubiquitous.
3. Hard-code certain axes indecies to have a different default value based on the controller type.
   • This requires the addition of a "controller model" parameter and a hard-coded list of supported models, configurations, etc. This quickly becomes untennable.
4. Allow users to provide a list of axes to be treated as "triggers" which start with a different default value.
   • This is my preferred implementation if any of you are interested in trying to work it in. There are still some caveats such as controller "mode" and switches which change the button layout but I think this is as close as we can get without disrupting the existing architecture.

I'd be happy to hear feedback.

[swiz23]

Hi @JWhitleyWork,

I understand the idea of using a default value of 0 for all the axes, and also now understand why the range is -1.0 to 1.0. But after setting the default axes to be 0, can't you do a one-time 'read' of all axes as part of the startup procedure, which would then automatically set the trigger buttons to 1.0?

FYI - I'm the same guy as @swinterbotix, but I've stopped using that username a few months ago.

[jlack1987]

Attempted fix to this issue in #214. I went with option 4 from #155 (comment)

[peci1]

This is (IMO) duplicate of already resolved #91. The fix is in #98 resp. #107.

The fix is, however, not enabled by default. To make use of it, set default_trig_val to true for joy_node.

[peci1]

I documented default_trig_val on ROS wiki.

[ARK3r]

I still see this issue in ros2 humble on Ubuntu 22.04 with a PS4 controller. I also cannot find anything in the humble-devel branch mentioning default_trig_val.

Is there a solution for this in humble?