Hello
Somehow the leftTrigger() and rightTrigger() from CommandXboxController are not triggering when used with our trusted Xbox 360 controller (and same for axisGreaterThan/axisSmallerThan when used against the triggers).
All the other buttons do work, as well as axisGreaterThan/axisSmallerThan when used against the left and right sticks of the controller.
Anyone else observing this issue? Thanks.
Can you share your code? Preferably as a github link
FRC2495-2023/OI.java at main · FRC2495/FRC2495-2023 · GitHub
line 100
note: bindings are currently commented out, but they were not working when present in the code
You have gamepadRT there instead of gamepadRTrigger? gamepadRT isn’t referenced anywhere else.
Yeah we renamed the variable after commenting out the call that did not work.
But I don’t think the problem is/was in the calling code that is straightforward. My question is more about anyone else having observed such issue, so we can consider it’s a known issue and wait for a fix.
We can’t test / help you debug code you can’t produce. I can 99.99% guarantee this is working from a library standpoint. We need the code that wasn’t working for you to help figure out what you were doing wrong.
If anyone encounters an issue (including you) you should file an issue on Github.
OK: when line 102 is uncommented out, it does not trigger.
Note that we also sporadically face the “Driver Station does not detect joysticks at startup” Known Issues — FIRST Robotics Competition documentation (wpilib.org) so we are not feeling 99.99% confident that joystick/controller-related things that were working in 2022 are working in 2023.
Only one thing is certain: the triggers do work with our 2022 code
FRC2495-2022/OI.java at main · FRC2495/FRC2495-2022 (github.com)
line 147
so it’s not a hardware issue.
This is a DriverStation bug not a WPILib bug. Would more effect if your controller is connected which you are saying it is.
I have created a test project that works fine here. If you have any code that can reproduce this problem I would be interested, but as of now I cannot replicate your issue. Your 2022 code is completely different (this code was even available in 2022), but I agree that it proves that the trigger is working on your controller but the Driver Station should also prove that. You are using the trigger, (the variable press buttons on the back of the controller) right? You are also pressing it more than half way right?
Thank you very much for looking into it. We agree that the DriverStation bug is not a WPILib bug. We were just wondering if the driver station may somehow fail to pass the state of the triggers to the WPILib in some obscure scenarios. Our team has a history of managing to encounter punishing bugs with the rio, the driver station and/or WPILib (such as the i2c issue in 2020 which remains unsolved to this date, the thread lock issue in 2022, etc)
We also agree that our 2022 code was completely different. It was simply mentioned to sustain that the hardware is working and that we are indeed talking about pressing the buttons in the back more than halfway.
We will check things again on Wednesday and report here.
At our meeting last evening, we ran into a case where the A/B/X/Y buttons on our xbox controller where not being recognized. If I recall correctly, closing and restarting the driver station and dashboard corrected the issue (we may have also power cycled the robot).
Yesterday, I also had a conversation with another team where the X and Y axis (not sure if same stick or two sticks) on a xbox controller would work for a while and then just stopped working. I suggested that they try what worked for us but have not heard back yet.
Could there be some sort of xbox controller / generic HID related network tables bug hiding out around here? Something else?
NetworkTables isn’t involved at all with joysticks from the DS. If the entire controller didn’t work, you maybe were running into this? Known Issues — FIRST Robotics Competition documentation
The controller is showing up fine in the driver station and tapping one of the buttons highlighted in the driver station correctly (I do want to verify this last point if it happens again), it just did not fire the bound command.
I should have written, “is there an issue with how the button press is communicated from the DS to the code running on the robot” rather than Network Tables. I made the assumption that that data was communicated between DS and robot via NT. I am a bit surprised to hear it is not.
Can you share a link to your code? Are you able to reproduce the problem in simulation (either with the real DS or using the sim DS)?
As a debugging step it could be useful to publish the button info to NT (eg SmartDashboard.putBoolean or similar) in teleop periodic (outside of the command framework). Seeing if the NT value changes when the command code doesn’t run will tell us if it’s the command framework or something lower level.
Try the link below but the GitHub repo may be private at this time. If it does not work, I could try to get it changed to public this evening. Note that the binding works for a while and then stops working without any code changes.
https://github.com/FRC4561TerrorBytes/TB2023/commits/FulcrumArmZeroing
BTW, I have heard back from the other team I mentioned (with the stick axes issues). They have some new interesting observations. I encouraged them to post to this thread (trying to get myself out of the middle) and got a thumbs up in discord. Hopefully we will see a post or two here soon.
We’ve been experiencing issues where the Driver Station randomly recognizes different axes with different configurations whenever it is asked to load USB Devices. So, whenever our USB Hub is unplugged and plugged back in, we put our computer into sleep mode.
The most notable difference to me between the configurations was the separation of the left and right trigger axis; in one instance, the two triggers were combined to create an axis that ranged [-1, 1], and in another instance, the two triggers were separated into two axes that ranged [0, 1]. In creating this additional axis, all of the subsequent axis ids were also pushed back by one, which caused our code to stop functioning correctly.
The issue on this thread seems similar to ours, which could suggest an issue with NI’s Game Tools this year, but I think there’s also a possibility that there is an issue with our Xbox Controller Drivers. We’re open to any suggestions for resolving this issue.
Following up on what @StarbuckBarista wrote, are the gamepad axes supposed to remain numbered the way they used to be in 2022 and before (i.e. LX 0, LY 1, LT 2, RT 3, RX 4, RY 5) or are they now dynamically numbered?
I now vaguely recall seeing some warning about a controller axis 5 not being found in the robot output yesterday (but working on something else and not really paying attention) …
As far as I’m aware, that shouldn’t have changed from previous years.
Thanks! Then could it be that something was changed on the driver station by NI (obviously something has changed somewhere as not finding USB devices was never a problem prior to the 2023 release of the driver station ) that the WPIlib team was not made aware of and is not accounting for?
Bonus question: are owners of PS4 controllers also observing such issue? With so little time before competition, wondering if a controller switch could mitigate the risk of having to play games without a fully reliable system …
