WPILIB mecanum code not working properly

[Ether]

Originally Posted by engunneer

It is not asking for field x and y but joystick x and y.

...unless you are using mecanum_Cartesian with a gyro signal connected to the gyro input. Then it is expecting field-centric inputs.

[engunneer]

Originally Posted by Ether

...unless you are using mecanum_Cartesian with a gyro signal connected to the gyro input. Then it is expecting field-centric inputs.

We were using all of those. The input parameter called x expects the x position of the joystick. The y parameter expects the y joystick position with no inversion. Our robot immediately started driving properly with field centric controls once this was straightened out.

[AWoL]

Originally Posted by cad321

wheelSpeeds[MotorType.kFrontLeft_val] = xIn + yIn + rotation;
wheelSpeeds[MotorType.kFrontRight_val] = -xIn + yIn - rotation;
wheelSpeeds[MotorType.kRearLeft_val] = -xIn + yIn + rotation;
wheelSpeeds[MotorType.kRearRight_val] = xIn + yIn - rotation;

to the following:

double mFL = strafe + forward + rotation;
double mFR = strafe + forward - rotation;
double mRL = strafe - forward + rotation;
double mRR = strafe - forward - rotation;

Maybe I missed something here, but may I ask why you changed the signs in the equations?

[krieck]

Looking at the code for RobotDrive, I can see that the gyroAngle is used to rotate the values of xIn and yIn. This is what creates the field-centric driving.

Your code that works appears to put the values of "strafe", "forwards", and "rotation" directly into the motor controllers.

Are you discarding the rotation from the gyroAngle to get driving to work normally? In other words, could you get good normal driving behavior by keeping the gyro angle at a constant zero?

[cad321]

Unfortunately I couldn't get my hands on the bot today as I was busy working on mechanical and also it was being used for our driver try out. Hopefully Monday I will be able to map out all off the wheel rotations. I also had two of our mentors go over and double check the wiring and neither could find anything wrong.

Originally Posted by TimTheGreat

Is there a reason your robot drive is *10*,1,2,3? did you mean 0? And make sure the order you set the drive motors is frontLeft, rearLeft, frontRight, rearRight.

No I did mean to say 10. The way our electronics are layed out, it was easier to run a short pwm cable to port 10 on the side car rather than 4. Also note that this is our practice bot and it is running the Crio/associated hardware, not the new RoboRIO.

Originally Posted by AWoL

Maybe I missed something here, but may I ask why you changed the signs in the equations?

I changed the signs in the equation because earlier on while troubleshooting we realized that, based on the movements of the wheels we were seeing at the time, there would be a chance that if we changed some of the signs around, we might see the movements we were expecting. Sure enough the robot started driving normally when we changed up the signs.

Originally Posted by krieck

Your code that works appears to put the values of "strafe", "forwards", and "rotation" directly into the motor controllers.

Are you discarding the rotation from the gyroAngle to get driving to work normally? In other words, could you get good normal driving behavior by keeping the gyro angle at a constant zero?

Originally I didn't even incorporate any gyro code as I just wanted to be sure we had basic functions before going any more complex. After I got the drive functioning properly (using the new equations as seen in my first post), I started working on gyro code. I now have standard mecanum drive working along with proper field centric control (again all using the new equations).

My next step is to try and get a PID loop running that keeps our heading to the desired angle as we are currently experiencing drift in our rotation. I have also been trying to get a velocity PID loop running on our wheels using encoders so that we can ensure that we are getting the desired RPM's out of our wheels.

[TimTheGreat]

And what is the problem of just using RobotDrive.MecanumDrive_Cartesian(joystick.getX(), joystick.getY(), joystick2.getX(), 0)?

That should give you exactly what you want without having to mess with the math of it

[Ether]

Originally Posted by TimTheGreat

And what is the problem of just using RobotDrive.MecanumDrive_Cartesian(joystick.getX(), joystick.getY(), joystick2.getX(), 0)?

That should give you exactly what you want without having to mess with the math of it

... and if it doesn't then do this.