View Single Post
  #8   Spotlight this post!  
Unread 16-02-2015, 20:01
cstelter cstelter is offline
Programming Mentor
AKA: Craig Stelter
FRC #3018 (Nordic Storm)
Team Role: Mentor
 
Join Date: Apr 2012
Rookie Year: 2012
Location: Mankato, MN
Posts: 77
cstelter will become famous soon enough
Re: Strafing Problem

I'm kind of lost in all the help that is being given. Why are folks talking about PWM=0 channels and the like when he is instantiating CANTalons? His ports are clearly 1=LF, 2=LR, 3=RF, 4=R and that is what should be checked for on the robot. If the talons feeding the motors are not numbered that way, then it could explain the issue. Our team made that mistake too and it can behave just as described. Having X from above and Diamond from below wrong can also lead to this.

MecanumDrive_Cartesian is documented thus:

/**
* Drive method for Mecanum wheeled robots.
*
* A method for driving with Mecanum wheeled robots. There are 4 wheels
* on the robot, arranged so that the front and back wheels are toed in 45 degrees.
* When looking at the wheels from the top, the roller axles should form an X across the robot.
*
* This is designed to be directly driven by joystick axes.
*
* @param x The speed that the robot should drive in the X direction. [-1.0..1.0]
* @param y The speed that the robot should drive in the Y direction.
* This input is inverted to match the forward == -1.0 that joysticks produce. [-1.0..1.0]
* @param rotation The rate of rotation for the robot that is completely independent of
* the translation. [-1.0..1.0]
* @param gyroAngle The current angle reading from the gyro. Use this to implement field-oriented controls.
*/


so according to that, all these negations should not be necessary unless the joystick is something exotic that inverts everything from typical -1, -1 being in the upper left corner.

Code:
             x = -leftJoystick.getX();
             y = -leftJoystick.getY();
             rotation = -rightJoystick.getX();
If they were necessary to make it drive right, the problem is still likely in your mechanism and wiring as the code says inverting x and y should not be necessary. I know it is not necessary if you are using the Logitech 3D or the older black joystick.

Our geaboxes (CIM Mini's I think') drive in the forward direction when positive voltage is applied when mounted on the left side. Since the same boxes are rotated 180 degrees on the right they drive in reverse with positive voltage. So one must tell the RobotDrive to invert the motors on the right side for our bot. JacobD gave good advice on how to do that-- his robot's gearing must be opposite of ours as they had to invert the left side.

Not adding the gyro until you have the rest sorted out was good advice too. By sending 0, it drives relative to the robot and you can be sure things are right.

Ether's advice and chart is golden too.

I also agree with Fletch1373 that RobotDrive initializes all motors in the invertedMotors array to +1 which means no inversion. The only way to flip one to -1 is to call invertMotor.

But folks asking for code (I believe he posted it in the original post, no?) and all this talk about PWM channels and especially which channel goes with which motor is irrelevant as long as the motors are wired according to the code. One could use channels/ports 5,8,2,1 for LF,LR,RF,RR and as long as the bot is actually wired that way and as long as the SpeedControllers are passed to RobotDrive in the correct order that the constructor requires them, it should not matter what the numbers are. This has me hoping the OP is not more confused than when he came here.

Just trying to clarify things. Hopefully I didn't miss something and will only be further muddying the waters, but it seems pretty clear.

Oh-- one thing I did spot in the code is that the code is allocating Joystick(1) and (2), instead of the standard (0) and (1)--. That's not an issue if you have joysticks at #1 and #2, but it's not typical.
Reply With Quote