Strange behavior not present in the code

hey folks, we are a rookie team and just finished our first qualifier this weekend. It went great, but in 3 out of our 5 matches, the robot acted weird when we started it in the field. For example, in one of them when the teleop began the wheels were stuck in an always “on” position so it would just spin in place (the driver was still able to get it to move by moving the joystick to “override” the rotation). In another, the joystick controller didnt work at all and instead the Dpad worked to control the robot. None of this was in the code (the wheels start “off”, and the Dpad is used to adjust launcher power, not control the wheels). We verified this wasn’t due to picking the wrong opmode, and were able to reproduce the behaviors right after the matches. The fix was generally a reboot (no code change). Fixing the “always on” behavior was to disable a code block, save/run, then re-enable the same code block (no code change), save/run. I dont know what to tell the students about why their robot works great at home and in the practice field at the competition but goes haywire on the actual stage. Do we have a busted control hub? Is it electrostatic charge? Is it due to wifi interference from all the spectators? Any thoughts are welcome.

Ooof! These kinds of problems can be extremely frustrating! Hopefully we can get you the answers you’re looking for.

For example, in one of them when the teleop began the wheels were stuck in an always “on” position so it would just spin in place (the driver was still able to get it to move by moving the joystick to “override” the rotation).

This is a common issue if the gamepad analog sticks are deflected before they’re plugged into the Driver Hub. What happens here is that when the gamepads are initially plugged in and powered on, the positions of the analog sticks are considered at “zero position” (center). If the gamepads are deflected at this time, when the gamepads return to their mechanical center they “appear” to be pushed in a direction opposite of the initial deflection - so there will always be an offset on the gamepads until the gamepad is disconnected and reconnected with the analog sticks centered.

In another, the joystick controller didnt work at all and instead the Dpad worked to control the robot.

This is a behavior of the default Logitech F310 gamepad. There’s a little button on the gamepad called the “Mode” button, and it has a little green LED next to it. If that button is pressed, the green LED will be illuminated, and what it does is swap the functionality of the DPAD and the Left Analog Stick (the DPAD now becomes the left analog stick, and the left analog stick becomes the DPAD). The mode functionality is incredibly useful for debugging and being able to have “digital” inputs for the left stick (allows you to have “true” up, left, right, and down - whereas with the analog you’ll almost always have some deflection in another direction as well). However, this can be very confusing if you accidentally press that button and don’t understand what it does and don’t realize you pressed it.

I hope this helps, if you have anything else to talk about we’re always here!

-Danny

This is so helpful, thank you! Any idea why disabling a code block and re-enabling it would solve the “wheels on” problem? Maybe that resets the controller?

I would very much bet that you didn’t realize someone unplugged and replugged the gamepad. Especially if the Driver Hub button was pressed to make it go to sleep, when you turn on the Driver Hub again you have to unplug and replug the gamepads - if you don’t realize that’s what happened, it likely wouldn’t stick out in anyone’s mind as being the reason it started working. But no, making any code changes wouldn’t have changed this behavior.

makes sense, thank you