Has anyone gotten weird results from the mecanum drive?

I was working of porting the labview code to java before the kickoff.
At first, the movement was working fine

RobotDrive mecanumWheels = new RobotDrive(1,2,3,4);
Joystick joystick = new Joystick(1);
mecanumWheels.holonomicDrive(joystick.getMagnitude(), joystick.getDirectionDegrees(), joystick.getTwist());

However, after the reimage and update of java code,

RobotDrive mecanumWheels = new RobotDrive(1,2,3,4);
Joystick joystick = new Joystick(1);
mecanumWheels.mecanumDrive_Polar(joystick.getMagnitude(), joystick.getDirectionDegrees(), joystick.getTwist());

the bot doesn’t strafe. Instead, the bot just goes forward, backward, and spins.
Is it a problem on my end, or on FRC’s end?

Have you put it up on blocks and made sure every wheel is powered? Some times you will get these symptoms if every wheel isn’t powered for strafe.

like i said, it worked perfectly before the 2011 java update
so i know the wheels aren’t the problem and neither is the wiring

Troubleshooting often involves checking things that you feel certain cannot be the reason for the malfunction. There are many different ways to develop a troubleshooting plan. Most succesful plans keep in mind Occam’s Razor. You are inferring that discovering the malfunction after the update indicates explicit causality, however there may be other reasons for the malfunction that are simple to check first. Among the simplest is to put the robot up on blocks and make sure the correct wheels are turning in the correct direction when given an input. This simple step can, at the very least, eliminate some very probable reasons for the malfunction before you dig deeper. Another easy to check cause is to make sure there isn’t some code further down that isn’t modifying the code that you showed us.

Our wierd symptoms included:
robot spinning while driving forward (gyro shorted on frame)
robot swaying like it was dancing (gyro hanging by pwm cable)
robot strafing but nothing else (two motors wired reverse)
robot spinning and strafing but not moving forward (two motors reversed in program)

We are having the same problem.
This might fix it, but I have not had a chance to try it yet.

You just described our team’s experience for the last week.
This thread explains the cause and solution:

We haven’t verified the solution but kudos to team 662 for the cause.

the bot doesn’t strafe. Instead, the bot just goes forward, backward, and spins.
Is it a problem on my end, or on FRC’s end?

Yes! We have the exact same problem on our 2010 robot when moving to mecanumDrive_Polar()!

One quick fix is to use mecanumDrive_Cartesian() with the x and y axes as input and a fixed 0 degree angle input. Not ideal though. We have some custom magnitude and direction code for our controller.

Not sure if this issue is our code or 2011 wpilibj. I’ll be looking into it this weekend.

See this thread: http://www.chiefdelphi.com/forums/showthread.php?p=1004753#post1004753

Bug in WPILibJ…

http://firstforge.wpi.edu/sf/go/artf1315

Yea, I just saw this update
Gonna hafta update the netbook tomorrow

We ran into another issue today. When strafing the robot goes diagonal. Output from two motors on opposing sides and ends (diagonal from each other) drops to zero which makes it go diagonal.

When we bypass the gyro in the code it goes perfect but doesn’t hold heading as to be expected without a gyro.

checked output on gyro and it derivatives about 0.05 degrees/second while sitting still.

Yeah, after updating the netbook, we STILL had problems
We are probably gonna write our own mecanum drive code or get the 2010 version
If anyone has the 2010 version on hand, could you direct me to the holonomicDrive.

If you are using mecanum_polar, the fix for that has not been posted yet. Don’t expect it to be working in the latest update. Please keep an eye out for the next update which will fix this. Or you can just change the cos to sin and rebuild it yourself.

-Joe

We already fixed the sin and cos, but it still wasn’t strafing. Even before the sin/cos was found, it was obvious for us that the motors aren’t inverting themselves right.

The odder thing is when we put arcade in on the mecanum wheels after inverting the back motors it was able to strafe fine. Granted, we could not go straight after the inversion but that is an entire other story.

We decided that it would probably be smoother going ahead if the code was rewritten as a way for us to not have to worry about it in future years

btw kinganu123: i was in class reading this thread on my phone and was going to respond saying our team has a similar issue, but the saw our number in the corner of my eye :rolleyes:. Also i haven’t had the chance to start yet. Wednesday I’m looking at it with one of my friends and it should be knocked out by at least Fri, or most of it at least

–Nagel