Driver Station Warning


Have a screenshot of the code for the robot container.
The Warning I am getting is Joystick Button 1 on port 0 not available, check if controller is plugged in
The Controller is plugged in and is correctly set in the Driver Station.

1 Like

That error means the code is not receiving info about a controller in port 0. Check the USB tab of the driver station to confirm you have a joystick/controller showing up in port 0. If it doesnt show up at all, confirm you have one plugged in to a USB port on that computer. If it shows up but in the wrong port number, its likely “pinned” to the other port. This can he unpinned by double-clicking on it.

Does that message continuously print, or just once? If its just once, does it recur every time you restart the robot/robot code?

1 Like

Just once and recurs every time I restart the robot/robot code

If the Joystick is working properly, I’d just ignore the error.

If the error only outputs once and nothing after that, It sounds like the joystick isn’t loaded up yet in the first loop but fixes itself in subsequent ones. If the USB wasn’t actually working, it would be constant errors.

1 Like

We were seeing this error today, it seemed to clear up after redeploying the robot code/rebooting the Rio. The driver station responded as expected to all button and joystick input. We never saw it again today, but is something we’re going to keep an eye out for.

I see the same behavior with my joystick button 3 (X) which has somewhat similar code to yours in RobotContainer.java:

  private void configureButtonBindings()
  {
    new JoystickButton(driverController, XboxController.Button.kX.value)
      .toggleOnTrue(
        new SequentialCommandGroup
        (
          new PrintCommand("toggle X button flywheel"),
          new SpinupFlywheelCommand(flywheelSubsystem, kDriverButtonFlywheelSpeed)
        ) );
  }

It happens often, maybe 20% of the time that I deploy or start the robot (not sure about frequency or Restart or Deploy or both, though). There is nothing wrong with the controller and all controller functions work fine including the button 3 (X). I presume there is some sort of race condition where the joystick is accessed by my code just before the joystick is ready to respond and then it’s ready soon thereafter since I don’t get a second message about the joystick being missing. The button binding does work perfectly despite the error message.

I was going to report the error when I could figure out the pattern. Maybe the responders here have shown enough of a pattern to WPILib developers such as @Peter_Johnson for them to know what is happening.

The thread title could be changed to Joystick button error message unavailable for an instant at robot startup.

Thanks for the reports, everyone. Your reports confirm that this race condition exists in Java as well and not only in Python.

If it’s only one warning at startup, it can indeed be ignored.

The issue is being tracked by JoystickButton initialization causes joystick warning · Issue #1198 · wpilibsuite/allwpilib · GitHub.

This is kind of expected behavior with one of the changes made in 2023, and would have been possible last year as well as a race condition.

Basically the new way joysticks work, they will never be valid during robotInit. However most Triggers read their supplier during initialization, which if they try to read a joystick will cause a joystick read, causing this warning.

This technically was possible in 2020 and later as well, but as a race condition on startup.

I’ll look and see if theres a way to cleanly solve this without causing any other issues on startup, like too long of delays.

Even a “long” delay is much better than having to ignore an error message (an unacceptable, perilous action). We want to know if the joystick is working or not before the end of RobotInit when we have to give thumbs up to begin the match. We’ll be adding a significant wait before binding commands to joysticks. Will that wait be effective? Thanks.

A wait in this case won’t do anything. You would need a wait with a DriverStation.refreshData() call afterward to actually update the caches. How long to wait will be <100ms if connected, but if you don’t have a DS connected when the robot boots, then unless you completely block robotInit until the DS connects (Which we won’t do), you can’t guarantee that anyway.

The reason this is a change this year is in previous years what DriverStation.refreshData did was completely asynchronous. It was a race on code boot vs robotInit. This year, because thats now an explicit call (That is called by the templates every loop so you don’t have to), that race doesn’t exist, and instead behavior is equivalent to always losing that race in prior years.

I pushed a PR that will add an up to 100ms wait for new DS data upon HAL initialize, and then in the robot base code, call DS.refreshData() right after HAL initialize. As long as the DS is connected this will work, but with no DS connected it will time out and just keep going. But with no DS connected, theres no error message anyway, so maybe thats fine.

We’ve had this error before, if it occurs only once, and the Joystick buttons work properly, then I’d just ignore it.

It may be possible to remove the warning by:

  • rebooting the RoboRIO
  • re-building your code
  • re-deploying your code
  • disconnecting the Joystick, then reconnecting it
  • use a different Joystick (sometimes Joysticks can get faulty or defective)
  • use a different USB port on your computer (USB ports often get faulty or messed up in some way)
  • close the FRC DriverStation Application (and also ShuffleBoard, SmartDashboard etc…) and re-open it again
  • turn off your robot and turn it back on
  • close then reopen WPILib vscode

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.