Today our buttons and axes randomly changed themselves for the SECOND TIME. Long story short, we had placed the whole electrical system and motors and everything on the robot temporarily. Today was our day to take it all off and put it back on (in somewhat different laces), but permanently this time.
After this, almost everything on the controller (logitech controller) simply made the robot turn left… I redeployed the SAME CODE that should have been on the cRIO and most of it works the same as it did. the X button (button 3) is still a little messy, but it could be that our window motor isnt powered correctly. There’s still a lot we need to look into. Today was a frustrating day for the whole team…
But anyways… has anyone had issues with a logitech controller (seemingly) randomly reassigning button maps??
The first thing that comes to mind is that you have the joysticks configured in the wrong order. Check the Setup tab of your driver station to make sure. Besides that, I’m not sure what could cause your problem.
I’ll doublecheck the setup tab monday, but we only have one joystick (it counts the whole controller as 1), and it was plugged into the same USB port I always use
EDIT: I love your team name! Legitimately made me laugh out loud
Its not that obvious either. For example, I traced the pwm wires THREE times. I know 100% without a doubt that they were plugged in the right slot, facing the right way. Yet the button that used to turn PWM 7 (“Shooter Arm”) now turns PWM 5 (“Shooter Motor 1”). But Pwm 5 and 6 (Shooter Motors 1 and 2) worked with the same buttons as before. Except Pwm 5 went backwards.
Theres a lot that just doesn’t make any sense. The CIM at pwm 5 might have the power cables backwards which would explain the backwards spinning, but everything else, i don’t have a clue
I think Alan has it. Somewhere on the controller there is usually a button, I think they call it mode. It toggles between two different mappings of POV and axes. The drivers know nothing about and can’t inform you that the joystick is in the wrong mode.
Yes it has X and D on the back. While one (i dont remember which) was far worse than the other, they were both very different from what they should have been according to the code and previous button mapping tests.
I know it matters which PWM slot you plug motor controllers into, but does it matter which slot on the PDB you plug the motors into? I don’t think it does, but IF it does, that could very well have caused it
The PDB circuits excluding the ones on the end for the cRIO, camera, and radio are interchangeable provided they have the right breaker installed. The SW knows nothing about them and they are not SW controlled.
One problem that we had was that tested code would suddenly start malfunctioning. 3 out of 4 drive motors started running on their own when they worked before. Our shooter wouldn’t run and our spike/compressor would not work. After debugging we found out it was the ribbon cable that goes from the c-rio to the sidecar, suddenly everything was working again.
Really? We have always found that DirectInput (D) works far better for us than Xinput. (As for the Mode button, that only switches the functions of the + pad and the left analog stick. You should probably keep the Mode light off.)
We found using DirectInput gave us access to all the functions on our fancy gamepads last year, while Xinput mapped some of the shoulder buttons as axes that weren’t supported by the Driver Station.
The PS2 game controllers we’re using this year have a mode button that needs to be on in order for them to work right. With it off, one of the thumbsticks and half the buttons don’t do anything we can detect.
Although, wouldn’t it be just easier to buy an Xbox 360 controller from the nearest Wal-mart/Gamestop? Those don’t require any special configuration and are plug-n-play for pretty much everything i’m pretty sure. From experience, trying to use cross-platformed console controllers other than 360 doesn’t work well, especially in emulation software.
