Strange instance with Arcade Drive

[pastelpony]

Whenever we deploy our code to the robot, the axises on our joystick are reversed. As a result, we have to feed the X axis on the joystick into the Y value of arcade drive and vice versa. Is this a normal occurrence? We convert the array value of the joystick axises to a cluster like in years past so that we could unbundle them by name.

[Kevin Phan]

This is not a normal occurrence. This year though there has been a small change from last year with how you get out the joystick values now, the joystick get vi now has two output terminals, one for the joystick axis values and one for the buttons. This means now the values are stored in arrays rather than clusters. This should imply that the vi index array should be used to determine which input to use. However, I would like you to look into the joystick configuration settings on the computer you have the joystick plugged in, there might be something off with its calibrations or how it is determining its axes. If you are still having issues with the joystick, take a screenshot of the LabVIEW code and maybe the configuration settings of the joystick.

[Greg McKaskle]

Anytime you cast types, this can happen. From looking at the template code, the assumption is that the joystick's first axis is X and second is Y. Check the cluster element order, and if you don't find the issue, post code or a screenshot.

Greg McKaskle

[Alan Anderson]

If one side's motors are running in the opposite direction from what the code expects, you'll end up with the robot going straight when you want it to turn and vice versa. This will make you think that the X and Y axes are swapped.

Double-check the Invert inputs on the Motor Open. Typically, the right side motors need to be inverted.

[pastelpony]

I might have to check the cluster list order. I'm assuming 0 is X and 1 is Y from the cluster. Thank you.

[pastelpony]

Even in default drive code, I'm having to invert the axes to get a normal drivetrain moving. What is with that?