If you are using ArcadeDrive, there is a bug in WPILib in my opinion. I have reported it last year and I am surprise to see it not fixed for this year. See code excerpt below:
If both moveValue and rotateValue are positive, I am expecting the robot to go forward and turn to the right by convention. But as you can see, when both values are positive and for demonstration purpose, let's say moveValue equals to rotateValue. leftMotorOutput will be zero and rightMotorOutput will be some positive number. This will make the robot to turn left, not right!
If you want to argue that my understanding of the convention is wrong, then please look at MecanumDrive_Cartesian and apply the same values (both Y and rotation being positive and equal and X is 0). You will see the left motor powers will be the sum of Y and rotation which are both positive and the right motor powers will be zero. So the robot is turning right. So the convention in mecanum drive is different from the arcade drive! So my conclusion is that ArcadeDrive is wrong.
Code:
WPILib\RobotDrive.cpp line 439:
if (moveValue > 0.0)
{
if (rotateValue > 0.0)
{
leftMotorOutput = moveValue - rotateValue;
rightMotorOutput = max(moveValue, rotateValue);
}
else
{
leftMotorOutput = max(moveValue, -rotateValue);
rightMotorOutput = moveValue + rotateValue;
}
}
Code:
WPILib\RobotDrive.cpp line 501:
wheelSpeeds[kFrontLeftMotor] = xIn + yIn + rotation;
wheelSpeeds[kFrontRightMotor] = -xIn + yIn - rotation;
wheelSpeeds[kRearLeftMotor] = -xIn + yIn + rotation;
wheelSpeeds[kRearRightMotor] = xIn + yIn - rotation;
BTW, the way we fixed it was to have our own DriveBase class that inherits the RobotDrive class. We then override the ArcadeDrive method that negates the rotation argument.