# Mecanum drive cartesian problems

We are trying to use the mecanum drive cartesian method provided by wpilib. We are having a problem with the axis in the controllers not working properly.
We are using an xbox controller with 2 joysticks instead of a flight stick with a rotational axis. We are using the x and y axis on the left stick for the x and y variables called in the method and the x axis on the right stick for the rotation.

What is supposed to happen:
The left stick controls forward/backward and strafe left/right.
The right stick controls rotation.

The problem:
For example, when I push forward on the left stick the robot turns, and when I push left on the right stick it strafes.
When i push the left stick left/right the robot spins wheels but its not the right direction and doesnt move.

Has anyone successfully used the wpilib mecanum drive methods, and could you give us some tips?

We do not have a gyroscope set up currently and that variable is set as 0. Would that affect anything?

I would check to make sure the motors are inverted correctly. Are you able to drive normally (arcade or tank)?

Sounds like your joystick axes are switched in the code. The rotation should be -1,1], I’m not sure if positive goes clockwise since I don’t have a drive base to test it with yet, but…

Cartesian is mostly used with gyro. I would recommend just trying polar for now, until you have a gyro set up.

With cartesian and gyro set to 0, the robot constantly thinks it has yet to rotate at all. So as a result, things might get wonky.

AFAIK, you should be able to use the cartesian methods without a gyro just fine. Internally the movement vector is just rotated by the gyro angle. Without a gyro, strafing will always be relative to the robot, so if you turn while strafing you will move in an arc.

*Mecanum cartesian can be used without gyro. You don’t need to use polar.

Put the bot up on blocks. Issue a pure forward command and note the direction each of the 4 wheels is spinning. Do the same for pure strafe right, and rotate clockwise.

We have fixed our robot, sort of.
We inverted one side of our robot and that fixed most of the problem.
The joysticks were opposite so we inverted those also.
now our robot works perfectly, except that our front is now our back and our back is our front. Other than that it is perfect. This is just a test chassis so direction isn’t a problem.

That can be fixed with some more inversions. Before I cleaned it up, our mecanum code used to invert inputs three or four times before they finally reached the motors.

Did you verify that the wheels are installed in the correct orientation? Rollers on diagonal wheels should point in the same direction, with opposite directions on each diagonal.

That’s necessary, but not sufficient.

X when viewed from top.

If it’s moving opposite to what you expect after inverting the motors on one side, then you inverted the wrong side. We needed to invert the right-side motors to get ours working properly.

Could someone post code for using mecanum wheels and a gyro? I have the mecanum wheels working great without the gyro. I am using Java.

We haven’t used mecanum wheels with a gyroscope at all. I would guess you have to create a gyroscope in the code and add it to the mecanum drive function.

You have to tell us what you want to use the gyro for. For field-oriented control? To correct minor drift when trying to drive straight? Both? Neither?

I would like to set up field-oriented control.

Are you using home-brew mec code, or WPILib robotdrive.java?

If the latter, mec cartesian has an input parameter for gyro. That gives you field-oriented control.

If the former, just grab the rotateVector code from WPIlib.

I am using the wpilib library and robotdrive. I believe that I have to reset the gyro and use getangle.

We got our Mecanum Drivetrain Code working in field coordinates in December; click for the code on github. This is based on cRIO, but shouldn’t need too much tweaking. This is built on the command based robot model.

Out of curiosity, why do you drive at 70% joystick readings in cartesian mode but full power in Polar mode?

Is there a purpose to Polar/Cartesian switch? Isn’t calling cartesian with gyro-angle==0 equivalent to to calling Polar? Perhaps it is meant to switch between field-centric and robot-centric?

Not sure the CommandBase class will work in this year’s lib so it may not just be load/go. Also, I think atan2 is on Math now, not MathUtils because we have proper java this year, so those are the obvious tweaks I see that will be necessary

I am having trouble finding the java code mentioned by GeeTwo.

Does this work better for you?
https://github.com/frc3946/MecanumDrivetrain/tree/master/src/edu/wpi/first/wpilibj/templates