The only unnecessary negation is your unnecessary negation. The setInverted calls are designed for debugging purposes only (e.g. if a motor is accidentally wired backward) and are not intended to be included in a final build of the robot code (in the case of the RobotDrive class. That method is intended to be used over flipping motor leads because it is more verbose and easier to replicate. For drive train, there should only ever be one drive configuration). I suspect that you are incorrectly calling the mecanum drive class in such a way that it would undo the inversion that you applied unto it, leaving only the negation found inside of the RobotDrive class.
Quote:
|
So RobotDrive should not be in the business of negating for me. Also, since pushing the joystick to the right will give you a positive number on the X-axis, you would expect a positive "rotateValue" on arcadeDrive would make the robot to turn right but NO, wpilib makes it to turn left.
|
These two statements are entirely contradictory. Firstly, you state that you should be in control of the specifics of the drive train (which... you are)... Secondly, you state that the rotate value of the motor should be inverted because that is more logical. Actually, on my controller, going right is actually a negative value which causes the robot to drive right. If this were switched to work with your controller, mine would stop working. Last year, we used a SpaceMouse that had Y inverted and X euclidean. The motors
Quote:
|
suspect nobody complains about it because people would just stick with one type of drive (either arcade, tank or mecanum but not switching between them) and they would just call setMotorInverted appropriately or negate the x/y axes of the joystick to compensate for it.
|
No, because we just do this
Code:
if(shouldBeArcadeDrive){
drive.arcadeDrive(joy.getRawAxis(KXbox.Move), -joy.getRawAxis(KXbox.Rotate))
}else{
drive.mecanumDrive(joy.getRawAxis(KXbox.Move), joy.getRawAxis(KXbox.Rotate))
}
Took me two seconds to write in this text box. Much easier than overthrowing the entire system and rewriting wpilib from scratch.
__________________
FRC Team 1684 - Head Programmer (2013-2016)
FRC Team 5460 - Programming Mentor (2015-2016)

FIRST in Michigan - Technical Crew (2015-continuing)